Windows NT Security, Part 1

Understand the mechanisms of NT's robust security system

Preventing unauthorized access to sensitive data is essential in environments in which multiple users have access to the same physical or network resources. Operating systems (OSs) and individual users must be able to protect files, memory, and configuration settings from unauthorized viewing and modification. OS security includes obvious mechanisms such as accounts, and passwords. However, OS security also includes less-obvious mechanisms for protecting the OS from corruption, preventing less-privileged users from performing actions such as rebooting the computer, and preventing the programs of less-privileged users from adversely affecting the programs of other users or the OS.

The stringent requirements of providing robust security influenced the design of Windows NT, which has earned a C2 security rating. This security rating puts NT on par with most UNIX systems. Although you're probably familiar with user accounts, groups, and NT's file and Registry security editors, you might find the way NT implements its logon validation, object protection, and privilege checking a mystery. Yet if you have a basic knowledge of what goes on behind the scenes in NT security, you'll know which security policies you need to install, and you can better protect your systems.

To help you gain a basic knowledge of NT security, I'm beginning a two-part look at NT security this month. I'll review what a C2 security rating is and what facilities an OS must include to earn a C2 rating. I'll discuss NT's security identifiers (SIDs), which NT uses to identify users, groups, computers, and domains. Next, I'll present an overview of NT's logon procedure, and I'll discuss local and network (domain) logon. Finally, I'll discuss access tokens. Next month, I'll conclude with a detailed description of object security access validation, client/server impersonation, privileges, and policies.

C2 Security
The US Department of Defense (DoD) National Security Agency (NSA) established the National Computer Security Center (NCSC, at http://www.radium.ncsc.mil) in 1981 to help the government, corporations, and home users protect proprietary and personal data stored in computer systems. The NCSC created a range of security ratings, which Table 1 shows, that measure the degree of protection commercial OSs, network components, and trusted applications offer. The NCSC assigned these security ratings in 1983 based on DoD's Trusted Computer System Evaluation Criteria (TCSEC). The security ratings are commonly known as the "Orange Book."

The TCSEC standard consists of levels of trust ratings, in which higher levels of security build on lower levels, adding more rigorous protection requirements. No OS has earned the A1 rating. A few OSs have earned B1, B2, and B3 ratings, including variants of HP's HP-UX (a UNIX system), Digital's Ultrix and SEVMS, Unisys' OS 1100, and Silicon Graphics' IRIX.

OSs that have earned the C2 rating include versions of IBM's OS/400 and Digital's OpenVMS. NT 3.5 (Workstation and Server) with Service Pack 3 (SP3) earned the C2 rating in July 1995. Microsoft reportedly submitted NT 4.0 for NCSC evaluation, but the evaluation process usually takes several years and is not complete at press time (Microsoft first submitted NT 3.5 in 1991). Because the security-related components in NT 4.0's architecture are virtually identical to those in NT 3.5's architecture, NT 4.0 will probably meet the C2 requirements.

To earn a C2 security rating, an OS must implement the following features: a secure logon facility, discretionary access control, auditing, and object reuse protection. A secure logon facility requires users to enter a unique identifier and password to identify themselves before it will grant them access to the computer. NT uses accounts for user identification and password-based logon for its default authentication mechanism.

When an OS implements discretionary access control, it lets all shareable OS resources associate with a block of information that specifies which users can perform operations on the resource. If you've viewed or set NTFS file or directory permissions or you've modified the security settings on Registry keys, you've seen a representation of NT's discretionary access control, which NT organizes as a list. The list elements describe the actions a user can and cannot perform on an object.

Auditing capability lets authorized users place watchdogs on resources that monitor and record users' failed or successful attempts to access the resources. The NTFS permission editors and the Registry provide access to NT's implementation of file system and Registry object auditing. All shareable objects in NT can have auditing enabled. But auditing can introduce unwanted overhead, so NT disables it systemwide by default.

To have object reuse protection, an OS must prevent users from seeing data that another user has deleted or from accessing memory that another user previously used and released. For example, in some OSs you can create a new file of a certain length and then examine the file's contents to see data that previously occupied the location on the disk allocated to the new file. This data might be sensitive information that another user stored in a file and then deleted. NT prevents this type of security breach by preinitializing file data, memory, and other objects when it allocates them. If you create a file, NT zeros the contents before you can access the file, which prevents you from seeing any data that existed previously in the file's location on the disk.

When NT earned its C2 security rating, NCSC also recognized NT as meeting two requirements of B-level security: Trusted Path functionality and Trusted Facility Management functionality. Trusted Path functionality prevents Trojan horse programs from intercepting a user's name and password as the user logs on. NT's Trusted Path functionality exists in the form of its Ctrl+Alt+Del logon-attention sequence. This sequence of keystrokes, the Secure Attention Sequence (SAS), causes an NT logon dialog box to pop up, which initializes a process that helps NT recognize would-be Trojan horses. NT bypasses any Trojan horse that presents a fake logon dialog when a user enters the attention sequence.

NT meets the Trusted Facility Management requirement by supporting separate account roles for administrative functions. For instance, NT provides separate accounts for administration (Administrators), user accounts charged with backing up the computer (Backup Operators), and standard users (Users). Microsoft is reportedly working on a B-level version of NT, but the company has not made a public statement about when it might release this version.

If you rely on NT's C2 security rating in your security decisions, you must keep in mind two important considerations. First, a C2 security rating is different from a C2 security certification. OSs and programs earn ratings, but individual installations must be certified. This distinction means that most NT installations are not C2 certified, nor would they necessarily want to be­security needs vary, and too much security can hamper productivity. You can use the Microsoft Windows NT Server 4.0 Resource Kit tool C2Config to help your NT systems meet the requirements for a C2 certification.

Second, NT earned its C2 rating as a standalone system, with no networking enabled. If you take your C2Config C2-certified system and attach it to your LAN, your system loses its C2 certification. Securing a network-based system is harder than securing a standalone machine, but if you keep up to date with service packs and security alerts, you can remain close to a C2 certification level.

SIDs
NT uses SIDs rather than names (which might not be unique) to identify entities that perform actions in a system. Users, local and domain groups, local computers, domains, and domain members have SIDs. A SID is a variable-length numeric value that consists of a SID revision number, a 48-bit identifier authority value, and a variable number of 32-bit subauthority or Relative Identifier (RID) values. The authority value identifies the agent that issued the SID, and this agent is typically an NT local system or a domain. Subauthority values identify trustees relative to the issuing authority, and RIDs are simply a way for NT to create unique SIDs from a base SID. Because SIDS are long and NT takes care to generate truly random values within each SID, it is virtually impossible for NT to issue duplicate SIDs on machines or domains anywhere in the world.

In text form, each SID carries an S prefix, and hyphens separate its various components. To see the SID representation for any account you are using, run regedit and open the HKEY_USERS key, as Screen 1 shows. This key contains the current user's profile and the default account profile, which is in use when no one is logged on locally. In Screen 1, the SID of the current account is

S-1-5-21-1463437245-1224812800-863842198-1128

This SID has a revision number of 1, one identifier authority of 5, (which represents the NT security authority), another identifier authority of 21 (which identifies the SID as not built in), three subauthority values, and one RID (1128). This SID is a domain SID, but a local computer on the domain would have a SID with the same revision number, identifier authority value, and number of subauthority values.

When you install NT, the NT setup program issues the computer a SID. NT assigns SIDs to local accounts on the computer: Each local-account SID is based on the source computer's SID and has a RID at the end. RIDs for user accounts and groups start at 1000 and increase in increments of 1 for each new user or group. Similarly, NT issues a SID to each newly created NT domain. NT issues to new domain accounts SIDS that are based on the domain SID and have an appended RID (again starting at 1000 and increasing in increments of 1 for each new user or group). The RID in Screen 1 (1128) identifies that SID as the 129th SID the domain issued.

NT also defines several built-in local and domain SIDs to represent groups. For example, a SID that identifies all accounts is the Everyone or World SID: S-1-1-0. Another example of a group that a SID can represent is the network group, which is the group that represents users who can log on to a machine from the network. The network-group SID is S-1-5-2. NT issues SIDs that consist of a computer or domain SID with a predefined RID to many predefined accounts and groups. For example, the RID for the administrator account is 500, and the RID for the guest account is 501. A computer's local administrator account, for instance, has the computer SID as its base with the RID of 500 appended to it: S-1-5-21-13124455-12541255-61235125-500.

Logon
NT implements a secure logon process that takes as input a username and password and returns as output to the OS SIDs that identify the user's account and the groups the account belongs to. In the first step of the secure logon process, NT recognizes the SAS and prompts the user for identification and a password. The winlogon.exe program is responsible for presenting NT's logon dialog boxes. Instead of containing a built-in user interface, Winlogon loads the interface dynamically. This strategy lets third-party vendors implement their logon interfaces. Logon interface packages are known as Graphical Identification and Authentication (GINA) libraries. The default logon interface, which presents the logon dialog box most of us are familiar with, is MSGINA (it's located in winntsystem32msgina.dll). NT's ability to replace the logon interface lets third-party vendors replace MSGINA with a proprietary GINA. For example, a custom GINA might recognize a voice command instead of Ctrl+Alt+Del as the logon sequence, or it might use a retinal scanning device to identify users.

After users identify themselves to a GINA with a username and password, the GINA sends the gathered information to the Local Security Authority Sub System (LSASS, in winntsystem32lsass.exe) process with a local procedure call (LPC) message. LSASS is the front end for logon authentication in NT. Authentication is the mechanism whereby NT validates the username and password and retrieves the SID information that identifies the user. Reflecting the configurability of Winlogon, LSASS uses a replaceable library as its authentication package. If you look at the Authentication Packages Registry value HKEY_LOCAL_MACHINESYSTEMCurrentControlSetCONTROLLsa, you'll see MSV1_0 listed as the LSASS authenticator. (MSV1_0 is in winntsystem32msv1_0.dll.) If you have File and Print Services for NetWare (FPNW) or Client Services for NetWare (CSNW), you'll see an authentication package for that as well.

LSASS calls MSV1_0 and gives it the username and password. Next, MSV1_0 determines whether the logon attempt is local (onto a workgroup or the local computer) or domain based. MSV1_0 consists of an interface component, a processing component, and a component called Netlogon, which I'll describe shortly. The interface component takes the password and encrypts it. If the logon is local or directed at a domain and the machine the logon is taking place on is a domain controller, the interface component passes the username and password to the processing component. The processing component uses the functions exported by the samsrv.dll library to look in HKEY_LOCAL_MACHINESAM, which serves as the local account database on NT, to validate the name and password. Figure 1 illustrates this local validation flow of control.

HKEY_LOCAL_MACHINESAM, which is also known as the Security Accounts Manager (SAM) database, is by default not viewable even from an Administrator account. Consequently, the SAM's content and layout are a mystery to most people. Looking inside the SAM probably won't provide you with any useful information, but if you're like me, you're curious about why NT keeps the SAM so secret. If you change the SAM's security settings (do so only in a nonproduction environment) and open it, you'll see something like Screen 2 on page 66. In Screen 2, you can see the Domains key, which contains all local account information beneath it. If the machine is a domain controller, the Domains key contains domain-account and computer-membership information as well.

Under the Account subkey, you'll find information pertaining to non-built-in aliases, accounts, groups, and computers. In Screen 2, you can see three add-on accounts (Administrator, Guest, and Joe) under AccountUsersNames. Three subkeys under AccountUsers have numeric names. The keys with numeric names correspond directly to the account names under the Names subkey, and the numeric names of these keys are the account RIDs (e.g., the Administrator account has a RID of 000001F4, which is the hexadecimal representation of 500). For the RID-name keys, you'll find two values, F and V, that contain account description, password policy, password (encrypted), and SID. Of course, all this information is in an undocumented format and will change in NT 5.0 (see the sidebar, "Logon in NT 5.0," page 68).

The Builtin subkey is a mirror of the Account subkey, but Builtin also contains information for aliases, groups, and accounts that are built in to NT. Unless you have a nonstandard security setup, you'll find in this subkey only built-in alias information that describes which accounts are members of aliases. For instance, under the Builtin subkey you'll find Administrators, Power Users, Backup Operators, and other aliases.

To validate a user logon, MSV1_0 looks up the specified logon account in the SAM and compares the password the user keyed in with what it finds in the SAM. If the information matches, MSV1_0 validates the user, obtains the SIDs of the account and the groups the account belongs to, and returns these SIDs to the interface component, which in turn passes the SIDS back to LSASS. LSASS finally obtains a list of privileges associated with the account and groups. An example privilege is User can reboot the computer. NT stores the privileges lists in HKEY_LOCAL_MACHINESECURITY. Like the SAM, the security database is thoroughly locked down, but I'll show you what's inside it when I discuss privileges next month.

The flow of logon control is different if the user logon is directed at a domain and the user machine is not a domain controller or if the logon is directed at a trusted domain. Figure 2 shows the flow of remote logon control. The MSV1_0 interface component presents the username and encrypted password to the processing component, which gives the username and encrypted password to the Netlogon component. Netlogon (winntsystem32etlogon.dll) sends the information to MSV1_0 on a server (chosen through a process called discovery) for the domain the logon is targeting; this server also has an instance of MSV1_0 running on it. Netlogon on the target server is listening for network authentication requests. When it receives a request, it hands the information to the processing component of MSV1_0. The processing component performs the same authentication and SID-retrieval steps as for local logons, but it gives the information to Netlogon on the target server, which returns the information to the originating computer's Netlogon. Finally, the originating Netlogon returns its results to the interface component of MSV1_0, which returns the results to LSASS.

I've just described interactive logons, in which a user sits at a computer and types in a username and password, but the flow of control is the same for noninteractive logons. For example, when a Win32 service (a daemon process) runs in the context of a specific user account, the service logs on to the computer by using account name and password information, which the service stores with its other configuration parameters. The difference between interactive and noninteractive logons is that an interactive logon results in the creation of an interactive window station, with a desktop GUI that programs can interact with. You can think of noninteractive logons as "headless" logons.

Access Tokens
If the interface portion of MSV1_0 returns a result to LSASS that confirms a successful logon, LSASS must create an access token. An access token stores all the information MSV1_0 gathered, including the account SID, the group SIDs, the collective privileges, and the account name. An access token is a complete description of a user from the viewpoint of NT security, and NT attaches a copy of the token to all processes that the user executes. For example, when someone performs an interactive logon, Winlogon executes a shell program (in most cases Explorer) and gets the ball rolling by attaching to the shell process the access token that LSASS returned through the GINA. When LSASS creates the first token, the user is officially logged on. If the user starts another program, such as Word, inside Explorer, the process Word is associated with will get a copy of the access token. When LSASS closes the last token belonging to a user, the user is officially logged off. Figure 3 depicts an access token's logical contents. When a process tries to access an object, such as a file, Registry key, named pipe, or even an unnamed synchronization object, the Security Reference Monitor subsystem (discussed in "Windows NT Architecture, Part 1," March 1998) uses the process' access token to determine whether to allow the access.

To Be Continued
Next month I'll describe the decision-making process the Security Reference Monitor uses when it processes access objects. I'll show you how server processes such as those a file server initiates can temporarily alter their identities to look like a client user through a mechanism known as impersonation. I'll wrap up this two-part look at NT security by discussing privileges and policies in depth.