Some of the main topics in this chapter are
This chapter examines Windows NT 4.0 security and answers questions about Windows NT 4.0 resource security problems. The chapter is divided into two sections, the first of which looks at a method of troubleshooting this type of problem. To develop a logical and successful approach to security troubleshooting, one must first understand how Windows NT 4.0 security is put together. The first part of this chapter, therefore, highlights the salient features of Windows NT 4's security architecture.
The second part of this chapter describes the tools available to help you isolate and rectify security-related problems. Although numerous utilities are available for this task--either direct from Microsoft or via third-party developers--the tools covered in this chapter illustrate the application of the methodology introduced in the first part of this chapter.
The troubleshooting methodology described in this chapter is dependent upon a thorough understanding of how users are identified and authenticated by the Windows NT 4.0 operating system. Because it might also be necessary to keep track of users who gain lawful access to a Windows NT server, this methodology also includes a quick look at auditing and how you can use it to solve security problems.
Following one or more of the general pathways described in this chapter enables you to track down security errors, user difficulties, or even breaches of network security. After you understand how Windows NT security is put together, the nature and symptoms of any particular problem should suggest which path to follow.
If the root cause of the problem relates to Windows NT security, checking how a particular object consumer--a user, for example--is identified or authenticated, evaluating the discretionary access to that particular object or auditing the behavior of both the object consumer and the object itself easily isolates and solves Windows NT 4.0 security troubleshooting problems.
When working in a secure operating system environment, being able to consistently and uniquely identify yourself to the system is crucial because your security context governs your ability to do specific operations (such as gain access to a server share or open a handle to a file, and so on) within the operating system. User identification, and subsequent authentication, is one of the major security concerns in a networked operating system such as Windows NT 4.
User identification and authentication are discussed in the following sections to highlight the underlying mechanisms that make them work. After you understand these mechanisms, you can resolve their problems better and more quickly.
User Identification. A unique security ID identifies users to the system. Security IDs are unique across time and space, meaning that there is no possibility (statistically speaking) of having two identical security IDs.
Furthermore, if a unique security ID is lost through deletion of an account, the security context of that user is also lost. This particular situation is to be avoided at all costs (usually by disabling the user account for a period, before eventually deleting it) because Windows NT uses this security ID to identify a user within the operating system (an important building block of Windows NT security).
Recreating the same user account (via User Manager for Domains) causes an entirely new security ID to be generated, and Windows NT does not recognize the previous and current accounts as being the same user (even if exactly the same user particulars were furnished during the user account creation). This is because of the highly unique nature of the security ID.
A security ID (and the associated security context) plays the same role, within Windows NT security, as one's passport (and associated entry/exit visa) does during international travel. Your passport identifies you uniquely to the authorities, whereas your visa dictates the terms of your stay within a foreign country.
Your security context, therefore, is the range of system-wide permissions and privileges that have been associated or assigned to your specific security ID. Because the security ID of a user is lost when the account is deleted, it is impossible to regenerate exactly the same security ID by re-creating the user account (using User Manager for Domains). This implies that because your security context is focused on your security ID, your security context is also lost when your user account is deleted.
In this discussion of user identification, the specific aspects covered include security identifiers, loss of security context, access tokens, the logon process, and passwords.
Security Identifiers. In the Windows NT 4.0 Registry, it's possible to trace a user by using the unique security ID assigned during the creation of the user account. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList enumerates the security IDs of all the users who have user profiles and are defined in the security accounts manager database. Furthermore, the ProfileImagePath entry contains the physical location of the user profile.
A security ID is a statistically unique number. In other words, never use a security ID value that represents a specific user to represent another user at a later date. All security IDs are created by using a combination of user information, time, date, and domain information. Security IDs are represented by using the following format:
The identifier authority value is probably the most important information contained in a security ID because this value identifies the agency that issued the security ID. Typically, the identifier authority represents a corporation or large organization.
Similarly, subauthority values identify subagencies involved in issuing the security ID. For example, Microsoft's Internet security framework involves the issuing of security certificates, needed for client authentication and access control. The security ID sub-authority values could identify a certificate authority that could be partly responsible for issuing a Windows NT security ID.
A Windows NT system has some predefined, well-known security IDs. A well-known security ID is a security ID whose value is constant across all Windows NT systems. In addition, some well-known security IDs are universal across all systems.
Loss of Security Context. A security ID is a highly unique value, and this value is used to accurately and consistently identify Windows NT security objects, in particular users.
If, however, this unique security ID is lost, the security context of that object is also lost. This can have serious repercussions on the security administration of the afflicted network. The only way to lose a unique security ID is to delete the corresponding security object, such as a user account.
For example, suppose a user who has a Windows NT account leaves his job at a particular company. Later, this user returns to a different job at the same company. When this user left the first time, the administrator deleted his user account. Now Windows NT no longer accepts this user's security credentials as valid. When the user returns, the administrator creates a new account, and Windows NT generates a new security ID for that account. The new security ID does not match the old one, so the user now has a brand-new security context within Windows NT--that is, the old security context is lost.
When this user logs on, Windows NT creates an access token to identify this user to the Windows NT security subsystem. This access token includes the new security ID for the user, as well as other security IDs for the groups to which the user belongs, plus other information (such as the user's name and the groups to which that user belongs). In addition, every process that runs on behalf of this user has a copy of this access token (which now contains a brand-new security ID for this newly created user).
Windows NT 4.0 refers to the security IDs within a user's access token whenever he tries to access an object. The security IDs are compared with the list of access permissions for the object to ensure that the user has sufficient permission to access the object. Because the security ID reflected in the ACL of the object is definitely not the same as the security ID contained within the user's access token, the user is denied access to the object by the Windows NT security subsystem. In other words, in this example, the user has lost his security context because of his loss of security ID.
Access Tokens. Before a user can do anything on a Windows NT system, she must log on to the system by supplying a username and password. Windows NT uses the username for identification and the password for validation. The following procedure illustrates the interactive logon process for Windows NT 4.
The initial logon process for Windows NT is interactive, meaning that the user must type information at the keyboard in response to a dialog box that the operating system displays on the screen. Windows NT grants or denies access based upon the information that the user provides. (Access tokens are discussed in more detail later in this chapter.)
The Logon Process. The WinLogon process consists of nine steps that provide a Windows NT user with an access token and a logon session with the operating system. The process of interactive logon is explained in the following steps:
2. When the user provides a username and a password (security credentials), the logon process calls the Local Security Authority (LSA).
The LSA ensures that the user has permission to access the system, and forms the center of the Windows NT security subsystem. It generates access tokens, manages the local security policy, and provides interactive user authentication services. The LSA also controls audit policy and logs the audit messages generated by other members of the security subsystem.
3. The LSA runs the appropriate authentication package. All user authentication in Windows NT 4.0 occurs using the LsaLogonUser API. LsaLogonUser actually authenticates users by calling an authentication package. The default authentication package that comes with Windows NT 4.0 is the MSV1_0 Authentication Package. The MSV Authentication Package uses the security accounts manager database as its database of users, and it supports pass-through authentication of users in other domains by using the NetLogon service.
4. The authentication package checks the user accounts database to see whether or not the account is local. If it is, the username and password are verified against those held in the user accounts database. If not, the requested logon is forwarded to an alternate authentication package.
5. When the account is validated, the Security Accounts Manager returns the user's security ID and the security IDs of any global groups to which the user belongs.
6. The authentication package creates a logon session and then passes the logon session and the security IDs associated with the user to the LSA.
7. If the logon is rejected, the logon session is deleted and an error is returned to the logon process. Otherwise, an access token is created, containing the user's security ID and the security IDs of Everyone and other groups. The access token also contains user rights assigned to the collected security IDs. This access token is returned to the logon process with a Success status.
8. The logon session calls the Win32 subsystem to create a process and attach the access token to the process, thus creating a subject for the user account.
The Windows NT security model must ensure that the programs that a user runs have no more access to objects than the user does. So, if a user is granted only read access to a file, then when he or she runs a program, that program cannot write to the file.
A subject is the combination of the user's access token plus the program acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs each user runs. When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects or system services.
9. For an interactive Windows NT session, the Win32 subsystem starts the Windows NT 4.0 shell (SYSTRAY.EXE) for the user.
After the validation process, a user's shell process (the process in which Explorer is started for the user) is given an access token. The information in this access token is used as a security reference for anything the user does or any process that runs on the user's behalf. Even threads that belong to any of the user's processes inherit a copy of this access token.
Because Windows NT can identify users and knows what each user is allowed to do, it can compare the access control list (ACL) for the object with the user's access token to determine what kinds of accesses, if any, are allowed for each user.
Passwords. User records are stored in the security accounts manager database. Each user has two passwords with which it's associated: the LAN Manager compatible password and the Windows NT 4.0 password. Each password is stored doubly encrypted in the Security Accounts Manager database.
The LAN Manager password is computed by encrypting a secret key with the clear text password by using DES encryption. In using data encryption, a plaintext message can be encoded so that it appears like random nonsense and is very difficult to transform back to the original message, without the secret key.
DES encryption is a symmetric algorithm, which is the most common type of encryption algorithm. It is known as symmetric because the same key is used for both encryption and decryption. Symmetric algorithms are very fast.
The Windows NT 4.0 password is based on the Unicode character set and is computed by using the RSA encryption algorithm. The RSA public-key cipher is popular for both encryption and signatures.
Although both the LAN Manager and Windows NT 4.0 versions of the user password are maintained (for compatibility reasons), only the Windows NT 4.0 version of the password is affected if the password is set or changed from a Windows NT client. All the existing user interface limits do not permit Windows NT 4.0 passwords to exceed 14 characters.
Passwords do not travel across the network during Windows NT 4.0 authentication. Instead, a random string is sent to the client. The client encrypts the string, based on the user's entered password and passes the result to the server. The server does the same encryption at its end, using the password it has on file for the user and comparing the string it develops to the string returned by the client. If they match, access is granted.
User Authentication. User authentication makes use of the user identification concepts discussed in the preceding section to provide a user legal access to both the operating system and its resources.
Two aspects of user authentication are discussed in this section: pass-through authentication and impersonation. Although it can be seen as being part of the user authentication role, discretionary access control is discussed later in this chapter to provide a natural division in the presentation of user authentication theory.
Pass-Through Authentication. In Figure 31.1, the user provides Windows NT with some logon credentials (Step 1). Although the user is physically located in Domain_B, his user account has been created in Domain_A (Step 2). The user is therefore providing logon credentials that cannot be authenticated within the local domain (Step 3). The logon request is passed (by the NetLogon service) to a domain controller in the trusted domain (Step 4), where the account is successfully authenticated and an access token can be awarded to this user (Step 5).
The NetLogon service implements pass-through authentication in three basic steps: by selecting the domain to pass the authentication request to, by selecting the server within the domain, and by actually passing the authentication request to the selected server.
Selecting the domain is straightforward. The domain name is passed to LsaLogonUser. The domain name is processed as follows:
The process of pass-through authentication permits a user to log on within a domain without having a user account defined within that domain.
The Windows NT 4.0 domain controller also confirms that the account exists locally. If so, the request is processed locally; otherwise, the domain controller tries to determine whether a trusted domain has the account. It does this by sending a mail slot message to each trusted domain. Each trusted domain responds, indicating whether or not it defines the account specified.
The request is passed to the first domain that responds affirmatively. If no domain responds affirmatively, this NULL domain is treated as an untrusted domain and the request is processed locally. If more than one domain responds affirmatively, only the first response is used.
The NetLogon service picks a server in the domain by a process called discovery. A Windows NT 4.0 workstation finds the name of one of the Windows NT 4.0 domain controllers in its primary domain. A Windows NT 4.0 domain controller finds the name of a Windows NT 4.0 domain controller in each trusted domain.
Subjects and Impersonation. An objective of the Windows NT 4.0 security model is to ensure that the programs a user executes have no more access to objects than the user does. If, for example, a user is granted only read access to a file, when he executes a program, that program cannot write to the file because the program has only inherited read permission from the user.
A subject is the combination of the user's access token plus the program acting on the user's behalf. Windows NT 4.0 uses subjects to track and manage permissions for the programs each user executes. When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context, therefore, controls what access the subject has to objects or system services.
The client/server model of Windows NT 4.0 defines two classes of subjects within its security architecture:
Generally, when a subject calls an object service, through a protected subsystem, the subject's token is used by the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.
Windows NT 4.0 enables one process to take on the security attributes of another through a technique called impersonation. By using impersonation, the server can change its security identity to that of the client. A server typically has more permissions to access system objects and resources (such as databases on the server) than the client requesting the specific service.
For example, when a request is delivered to the server through a named pipe, the server changes its security identity to the security identity of the client. This limits the server to only those permissions granted to the client rather than its own permissions. This has the effect of increasing the security of named pipes.
All Windows NT 4.0 resources are represented as objects that can be accessed only by authorized Windows NT 4.0 services and users. An object in Windows NT 4.0 is defined as a set of data used by the system and the set of actions that manipulate that data.
This definition can be applied to any object used by the system, including memory, printers, or processes. Windows NT 4.0 objects include directories, symbolic links, printers, processes, network shares, communication ports, devices, windows, files, and threads.
A file object, for example, consists of data stored in a file and a set of functions that enables you to read, write, or delete data in that file.
In this section, the implementation and application of discretionary access are discussed. Some topics restate material in previous sections, but here are focused on the discussion of discretionary access. The topics under discussion include access tokens, security IDs, ACLs, access control entries, permission checking and its optimization, and the security reference monitor.
Access Tokens. When a user's process attempts to access any object, Windows NT 4.0 checks the user ID and list of groups in the user process's access token against the object's ACL. This check determines whether or not the user is granted the requested access to the object. The access token is permanently attached to each of the user's processes and serves as the process's identity card when it attempts to use system resources. Access tokens are objects and have attributes and services just like any other system object.
Security IDs. Although user and group identifications are represented here as names, the computer actually stores this information as a security identifier and group security identifiers.
A security identifier (SI) is a unique identifier used to represent a user, and a group security identifier is a unique identifier that represents a group or some type of security authority. Security identifiers are used within access tokens and ACLs instead of usernames or group names. An SI is represented as a unique number.
When users are identified by SIs, each instance of the account name has a unique SI, even though the same user account name might have been created multiple times on the same computer. For example, if you have user account for User-1, delete it, and then create a new account for User-1 by using the same name, the new account does not have access to the same resources as the old account. Although the account name is the same, the SI is different.
Access Control Lists. All functions used to access an object, such as opening a file, are directly associated with a specific object. In addition, the users and groups that are permitted to use the function are also associated with the object. Only users with the appropriate rights are allowed to use functions on an object. As a result, functions from one process cannot access objects that belong to another process.
This characteristic of objects provides built-in security. Access to each object is controlled through an ACL, which contains the user (and group) accounts that have access and permissions to the object. When a user wants to access an object, the security subsystem checks the user's SI and group membership, with the ACL to determine whether or not the requested object access is permitted.
Administrators and users with Change Permissions enabled can use CACLS.EXE (located in the \system32 directory) to show or modify ACLs for directories and files. If you query ACLs for directories, the output is a listing of the permissions on the directory and the files inside the directory.
Under Windows NT 4.0 Explorer in the Directory Permissions dialog box, the first set of parentheses contains directory permissions, and the second set contains file permissions. When using the CACLS utility, however, this information is displayed differently; the first listing of a group or user contains the file permissions, whereas the second listing contains the directory permissions.
A full list of the CACLS syntax can be obtained by executing the CACLS utility from the command prompt with the /? Switch. The following is the short form of the syntax:
Some examples might help to clarify the syntax and usage of this utility:
cacls <file name|folder> /e /r <user name>
/e = edit ACL
/r = revoke user rights
2. To grant a user specific rights to a file or folder, use the following CACLS syntax:
cacls <file name|folder> /e /g <user name>:<permission>
/g = grant specified user rights
3. To replace a user's rights to a file or folder, use the following CACLS syntax:
cacls <file name|folder> /e /p <user name>:<permission>
/p = replace specified user rights
The format of the output is as follows:
<directory name> <user/group>:<file permission>
<user/group>:<directory permission>
Each set of access control flags is followed by a single character that indicates the nature of the object access. For example, the "C" in DISC-WORLD\Domain Admins:(OI)(IO)C means that the Change right has been assigned to this directory for the DISC-WORLD\ Domain Admins global group. The complete list of access rights is:
The letters in parentheses represent the access control flags set for the object and container (in this case, the "secure directory" directory object). These access control flags, for file and directory permissions, are discussed next.
File Permissions. Two file permission indicators are evident in CACLS output:
The OI access control flag is applicable to permissions for files copied to or created in this directory. It means that this access control entry is inherited by non- container objects, such as files created within the container object to which the access control entry is assigned.
The IO access control flag is applicable to permissions for files copied to or created in this directory. It means that this access control entry does not apply to the container object but to objects contained by it.
Normally both references are present in CACLS output.
Directory Permissions. Two directory permission indicators are evident in CACLS output:
The CI access control flag is applicable to permissions for the directory and directories copied to or created in this directory. It means that this access control entry is inherited by container objects, such as directories.
The NP access control flag is displayed when a permission is not to be inherited. This means that the MSG_CACLS_OBJECT_INHERIT and MSG_CACLS_CONTAINER_INHERIT bits are not propagated to an inherited ACE.
A directory's ACL normally contains at least two ACEs. If CACLS output contains only one ACE, permissions for the other ACE have not been specified. NT Explorer, in this case, displays the ACE as "(Not Specified)".
Access Control Entries. Every user of the system needs to have a user account that can be added to resource ACLs. This requirement, for a user account, also applies to applications and services that need to access resources. When an administrator grants access to a resource, the user account is added to the ACL for that resource along with any specific permissions.
Each entry in the Directory Permissions dialog box and each pair of entries in the CACLS output is called an access control entry. Each entry identifies a user or group and the permissions that have been granted or denied for the object. An access control entry is added to the ACL for each user or group that is granted or denied access to an object.
Entries that deny access are listed first in the ACL, and entries that permit access are listed next. The only time this order is changed is when a company has written its own application that edits the ACL of a resource. In this case, a company can place the access control entry anywhere in the ACL.
Access to resources begins with the user logging on. Windows NT 4.0 requires that users log on before they can access any resources. When a user successfully logs on, she receives an access token that remains with the user process until logging off. Each time the user attempts to access a resource, the access token is compared to the resource ACL to determine whether access is granted or denied.
Checking Permissions. Windows NT 4.0 requires each user to provide a unique user name and password to log on to a computer. This mandatory logon process cannot be disabled.
When a user logs on to Windows NT 4.0, the security subsystem creates an access token for the user. The access token includes information such as the user's name and the groups to which the user belongs. Access to the system is allowed after the user has received this access token. During the time a user is logged on to a system, she is identified to the system by this access token.
Windows NT 4.0 compares the information in the access token to the information in the ACL to determine whether access should be granted. When a user attempts to access a resource on the system, the security subsystem compares the user's access token to the ACL to validate or deny the requested permission to the resource. The security subsystem follows these steps:
2. The security subsystem checks to see whether the type of access requested has been explicitly granted to the user or any of the groups in the user's access token.
3. The security subsystem repeats steps 1 and 2 for each entry in the ACL either until it has encountered a deny or until it has accumulated all the necessary permissions to grant the requested access.
4. If neither a deny or a grant appears in the ACL for each of the requested permissions, the user is denied access.
Optimizing Permission Checking. When Windows NT 4.0 grants access to an object, what it really does is give the user's process a pointer (handle) to the object. A handle is an identifier used internally by the system to identify and access a resource. The system also creates a list of allowed permissions called the list of granted access rights. This information is then stored in the user's process.
This way, an ACL is checked only when the object is initially opened. Subsequent actions performed on an opened object are checked against the list of granted access rights that have been stored in the user's process table for that handle.
The Security Reference Monitor. The security reference monitor is the Windows NT 4.0 component that determines whether or not a process should be granted rights to access an object (see Figure 31.2). It determines access rights by comparing the process's access token with the ACL of the object the process is trying to open. This section examines how the comparison process used by the security reference monitor impacts Windows NT 4.0 support.
The security reference monitor is responsible for access validation and audit checking within the Windows NT 4.0 security model.
When an open resource connection request, such as net use, is passed to the network redirector (which forms part of the Windows NT 4.0 installable file system), it does not use the token to check ACLs. The redirector, with help from components such as the security reference monitor and local security authority, maps the token back to the user credentials that were originally passed to the WinLogon process when the local user logged on (that is, the time when this token was generated).
To keep track of selected user activity, one can audit certain security events and log output into a security log. This auditing can be enabled by using the Audit Policy dialog box provided by the User Manager for Domains.
When administering domains, the Audit policy affects the security logs of the domain controller and of all servers in the domain because they share the same Audit policy. When administering a computer running Windows NT 4.0 Workstation or a Windows NT Server (as an application server), this policy affects only the security log of that computer.
Because the security log is limited in size, selecting every possible logging option does not allow for a long duration of security auditing. The maximum size of each computer's security log is defined in Event Viewer. Entries in a security log can be reviewed by using Event Viewer.
Windows NT 4.0 includes auditing features you can use to collect information about how your system is being used. These features also enable you to monitor events related to system security, to identify any security breaches, and to determine the extent and location of any damage. The level of audited events is adjustable to suit the needs of your organization.
When you enable auditing, each audit check the system performs has some small performance overhead. Some organizations need little auditing information, whereas others are willing to trade some performance and disk space for detailed information that can be used to analyze the system.
Tracking Security Events. Windows NT 4.0 can track events related to the operating system itself and to individual applications. Each application can define its own auditable events. Definitions of these events are added to the Registry when the application is installed on your Windows NT 4.0 system.
You can locate the event message files (the location of Event Viewer messages for a specific application) in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\EventLog key. This key is divided into three separate subkeys--Application, Security, System--and each application is registered beneath the applicable entry.
The corresponding registry value for the WinLogon application is located beneath the \EventLog\Application Registry key. This means that this application (%systemroot%\ system32\winlogon.exe) reports to the Application log (located in \system32\config\ AppEvent.evt) as WinLogon.
Audit events are identified to the system by the event source module name and an event ID. In addition to listing events by event ID, the Security Log in Event Viewer lists them by category. Table 31.1 shows the categories of events that are displayed in the Security Log. (Those in parentheses are found in the Audit Policy dialog box of User Manager.)
| Category | Meaning |
| Logon/Logoff (Logon and Logoff) | These events describe a single logon or logoff attempt, whether successful or unsuccessful. Included in each logon description is an indication of what type of logon was requested or performed (that is, interactive, network, or service). |
| Object Access (File and Object Access) | These events describe both successful and unsuccessful accesses to protected objects. |
| Privilege Use (Use of User Rights) | These events describe both successful and unsuccessful attempts to use privileges. They also include information about when some special privileges are assigned. These special privileges are audited only at assignment time, not at time of use. |
| Account Management (User and Group Management) | These events describe high-level changes to the user accounts database, such as User Created or Group Membership Change. Potentially, a more detailed, object-level audit is also performed. (see Object Access events.) |
| Policy Change (Security Policy Changes) | These events describe high-level changes to the security policy database, such as assignment of privileges or logon capabilities. Potentially, a more detailed, object-level audit is also performed. (see Object Access events.) |
| System Event (System) | These events indicate something affecting the security of the entire system or audit log occurred. System shutdown and restart are also included with (but are separate to) system events. |
| Detailed Tracking (Process Tracking) | These events provide detailed subject-tracking information. This includes information such as program activation, handle duplication, and indirect object access. |
Using Events to Track Users and Files. One of the most important aspects of security is determining who is responsible for the actual operations of security interest--file writes or security policy change, for example. Although a thread that requests access to a resource is identified by the user ID, the thread may be impersonating someone else. In this case, logging events by user ID may be misleading and may not be useful in finding the perpetrator in the case of a security breach.
To solve this problem, two levels of subject identification are used in Windows NT 4.0 auditing and in the security log. These are the user ID (also called the primary ID) and the impersonation ID (also called the client ID). These two IDs are used to determine who is performing auditable actions.
In some cases, however, a security administrator wants to see what is happening with each process. To meet this need, auditing information also includes a subject's process ID where possible.
When process tracking is enabled (through the Audit Policy dialog box of User Manager), audit messages are generated each time a new process is created. This information can be correlated with specific audit messages to see not only which user account is being used to perform auditable actions but also which program is running.
Many audit events also include a handle ID, which can associate the event with future events. For example, when a file is opened, the audit information indicates the handle ID assigned. When the handle is closed, another audit event with the same handle ID is generated. With this information, you can determine exactly how long the file remained open. This could be useful, for example, when you want to assess damage following a security breach.
Here's some of the information Windows NT 4.0 tracks within a process's access token:
The three major aspects of Windows NT 4.0 security--identification and authentication, discretionary access, and auditing--are presented in the first part of this chapter. Together, they form the components of a strategy to solve security-related problems. How these components are used and what tools are available to assist form the thrust of this section.
The toolset presented is divided among these three central aspects, and where possible, examples are presented to clarify their application.
Problems with identifying and authenticating users in a Windows NT environment invariably arise from incorrect credentials (username and password) or from mismatching of the parameters associated with user identification and authentication.
This section covers the various tools and concepts relating to the identification and validation of a Windows NT 4.0 user. This is not a trivial task, and requires a sound understanding of how a user is identified to the system, and how the system in turn validates this user during the logon process.
The focus of this section, therefore, is the logon process and when it can fail. User Manager for Domains plays a central role during the problem-solving phase of user authentication and validation.
User Identification. Windows NT 4.0 makes use of mandatory logon, thereby forcing users to identify themselves to the system. This practice ensures that only valid users are able to log on to the system. If you don't supply credentials that are recognized by the local security authority of a particular workstation or domain, you aren't permitted to gain access to the system.
Troubleshooting problems of this nature, therefore, is a simple matter of ensuring that proper credentials are supplied during the logon process. To determine proper credentials for a particular user, an administrator must view the Security Accounts Manager's database via the User Manager for Domains Utility.
If a user's logon credentials are rejected, then either the correct username (or spelling of the username) should be determined by editing the user account by using User Manager for Domains, or a new password must be provided using the same utility. (Remember that passwords are case-sensitive and have a maximum length of 14 characters.)
Losing Your Unique Security Identifier. Earlier in this chapter, reference was made to the problems attendant to deleting and re-creating a user. This is a classic problem associated with the way in which Windows NT 4.0 user accounts are created.
Deleting and re-creating user accounts is not recommended. In fact, the immediate removal of user accounts is unnecessary. Rather, Windows NT user accounts should be disabled; this prevents the total loss of the unique security Identifier associated with this account and ensures that the security context of this user is not completely lost.
One common practice is to find replacements for personnel who leave a company. The high turnover of personnel in the information technology industry has necessitated this human resource practice. Windows NT 4.0 accommodates this industry quirk by allowing specific user accounts to be disabled for a period of time (until a replacement for the employee can be found) and then renamed to reflect the new employee's own name.
The result of disabling and then renaming user accounts is that, although the actual employees may come and go, the security context for the various user accounts is always retained. This not only ensures that security account administration is greatly simplified, but also ensures that the Windows NT 4.0 security remains consistent. This rather simple way of reducing the overhead associated with turnover and ensuring consistent Windows NT 4.0 security is invaluable in large corporate network environments.
Presenting Your Credentials. On a stand-alone Windows NT 4.0 workstation or application server, logging on requires valid credentials that can be found in the security accounts manager database on the local machine.
When logging on to a domain, however, the logical location of the user credentials is of paramount importance. The use of the word logical in this instance refers to the conceptual point of authentication for any user, and implies that the physical location of any user within a domain model is irrelevant.
Often, a user (who is a member of a resource or trusting domain) is validated by a domain controller in an entirely different (master or trusted) domain. Because the user is not physically located within the master or trusted domain but merely authenticated within this domain, the authenticating domain is referred to as the user's logical location.
For example, a user might work in one particular physical location (Cape Town, for example), but the user account used to authenticate this user might be maintained in a user accounts database in another physical location (Johannesburg, for example). This is typical of the Windows NT 4.0 domain models that are implemented in modern corporate Windows NT networks.
The trick is to establish where the user is to be authenticated and then supply the name of the domain that contains the appropriate user account in its security accounts database. The point is that you cannot log on to a domain unless you have a valid username and password in that domain's security accounts database.
A hypothetical corporation, Acme Widgets, has corporate headquarters in New York (U.S. sales region) and Rome (European sales region). Houston, Boston, and London also have regional offices. The Windows NT 4.0 network has been installed by using the multiple-master domain model, as illustrated in Figure 31.3.
In Figure 31.3, a user in any of the five domains in this model can make use of a single logon account and gain enterprise-wide access to resources. The issue is how to provide the proper security credentials to ensure successful user identification.
The Acme Widgets--Multiple-master Domain Model provides enterprise users global access to resources, while maintaining a single user account and logon for every user.
A user who lives in Boston and works for the U.S. sales group is authenticated by the trusted domain responsible for account management in the U.S. sales region (New York). Therefore, when prompted for logon credentials, the user must provide New York for the domain (or logical location of user account).
User Authentication. Windows NT 4.0 has three forms of authentication. These include interactive logon authentication (via the keyboard), which was discussed earlier in this chapter (see the section titled "The Logon Process"), remote logon authentication, and pass-through authentication.
After the correct credentials have been supplied to the WinLogon process, these credentials must be authenticated before access can be granted to the Windows NT 4.0 Executive services and any resources they protect.
Remote Logon Authentication. Access to resources is not only applicable to local resources, but also to resources that are maintained and advertised by other computers on the same network. Access to these remote resources must also be controlled in the same way in which local resources are protected, and remote logon authentication can also present problems similar to those experienced with local resource authentication. Despite this apparent difference in authentication methods, the way in which Windows NT 4.0 handles them is almost identical.
Troubleshooting remote logon authentication must, therefore, proceed in a similar manner as local logon authentication problems are resolved. The basic requirement is a valid user account and password; for remote logon authentication it must be local to the remote Windows NT 4.0 computer that has the targeted resource. In other words, the user credentials on the local and remote Windows NT 4.0 computers must be identical for seamless access to the appropriate resource.
If the common credentials are not identical, Windows NT 4.0 attempts to resolve the missing credential. For example, if the usernames are the same but the passwords are different, Windows NT 4.0 prompts the user for a password. After this password has been provided and checked, access to the resource is permitted. If neither the username or the password matches, access to this remote resource is denied.
Pass-Through Authentication. Pass-through authentication is a function of the NetLogon service, requiring the presence of at least two domains and a trust relationship between them. Problems relating to pass-through authentication, therefore, invariably originate from problems with the implementation of a Windows NT 4.0 domain.
To troubleshoot pass-through authentication, an administrator must typically verify the appropriate trust relationship, as well as determine that the user account has been correctly created in the appropriate accounts domain.
Figure 31.3 (shown earlier in the chapter) illustrates the multiple-master domain model for the Acme Widget corporation. When a user in the Boston domain logs on, the logon authentication request is sent to the New York domain for two reasons. First, New York is the U.S. regional headquarters and has the necessary centralized expertise to administrate the U.S. sales region effectively.
Second, the user account has been defined in the security accounts manager database in the New York domain. For user authentication to be successful, the following three tasks must be correctly carried out:
2. The user account for the user who is being authenticated must be created by using User Manager for Domains on any of the domain controllers within the New York domain. This is possible only if the primary domain controller is switched on and available.
3. The user must correctly specify the username, password, and domain name during the logon phase (the WinLogon process). The username and password must match those credentials supplied by the administrator when the account was created in the New York domain. The domain name in this example is New York. This can be visually verified when the user types in the necessary logon credentials during the WinLogon process.
After a user gains legal access to a Windows NT 4.0 machine, the operating system must be able to validate her access to the underlying objects and resources for which this user has specific access rights and privileges.
In the section "Tracking Security Events" earlier in this chapter, you learned that users can be tracked and validated via their access tokens or by a process of server impersonation. This implies that access can be gained to a security object directly (by means of the user access token) or indirectly (by means of server impersonation).
Either way, a user can experience problems when trying to access a system or user object, and a method is required to find out why this problem has occurred. The two common problems areas are the access token (associated with the user) and the ACL (associated with the object being accessed).
The process of troubleshooting problems of this type, therefore, involves finding out what effective rights the user has to the associated object, as well as finding out what access is permitted with respect to the associated object. Here's the basic process:
2. Determine whether or not the effective user rights (as determined in the preceding step) give the user sufficient permission to gain the access to the object that is being requested (read access, for example).
3. If steps 1 and 2 have been completed successfully, the Security Reference Monitor grants the desired access rights to the object. Otherwise, access is denied.
Effective User Rights. Two specific concepts govern the effective rights that a particular user has. The first is the cumulative user and group rights assigned to a security object. The second is the most restrictive nature of local and network rights assigned to a security object. The most common problems in this area stem from the peculiar relationship between these various types of security rights.
User and Group Rights Are Cumulative. User and group rights are cumulative. In other words, the effective rights of a user are the accumulation of rights assigned directly to the user account, as well as any rights assigned to groups to which this particular user is a member. An exception to this rule is the No Access permission. The No Access permission overrides all other rights. Table 31.2 presents an example of how these cumulative rights are derived.
Table 31.2 Cumulative User and Group Rights
| User/Group | Assigned Rights to E:\SecureDirectory |
| wayne | Full Control |
| Domain Admins | Change (RXWD) |
| Domain Users | Change (RXWD) |
| Effective Rights | Full Control |
To construct this table and establish the effective rights of a particular user or group to a security resource, you must complete the following steps:
2. After these groups are identified, they can be entered on the left side of the table (refer to Table 31.2), and an administrator can use Windows NT 4.0 Explorer (to view the properties of the subdirectory) to determine the assigned permissions to this resource for every applicable User/Group in the table.
Table 31.2 combines this user/group security information, and displays user wayne's effective rights to the directory object (which is Full Control). It should be noted that, if user wayne were a member of Domain Guests, the effective rights to this directory object would be No Access.
Local and Network Rights Are Most Restrictive. Windows NT 4.0 server advertises its resources through the process of sharing. Most utilities (NT Explorer, Print Manager, and so on) have the capability to advertise directories and printers to clients by using a server `share.'
Assuming that user wayne could obtain access to this resource (E:\Secure Directory) across the network via server share, the permissions set on the share would also come into play.
In this case, the same process would be followed (as tabulated in Table 31.2) to determine the effective rights to the server share. Assume, for example, that the effective rights to this share are only Read (RX). Further, assume that the effective user and group rights are in fact Change (RXWD).
Because local (effective user and group rights to the NTFS file/directory) and network (effective user and group rights to the server share) rights are most restrictive, user wayne obtains the most restrictive effective rights (see Table 31.3) of Read (RX).
| Object | Effective Rights |
| Local Rights | Change (RXWD) |
| Network Rights | Read (RX) |
| Effective Rights | Read (RX) |
Permitted Object Rights. After the effective rights of a user have been ascertained, the local security subsystem must compare these effective user rights to the permission level being requested by the user on the security object. The local security subsystem never permits security access to an object that exceeds the user's effective rights to that object.
Setting the permissions to an object can be achieved using a plethora of different utilities, either programmatically or directly. In the current example, Windows NT 4.0 Explorer can be used to assign specific NTFS directory- and file-level permissions. In the event of an access error, Windows NT 4.0 Explorer can also be used to determine or verify these assigned permissions.
A fast way to resolve resource access problems is to use the CACLS and WHOAMI utilities (WHOAMI is a resource kit utility). The basic idea is to visually determine the effective rights of both the user and the resource in order to determine where this particular user is losing the necessary permissions to access this resource.
For example, a user is trying to access a subdirectory (E:\SecureDirectory) located on an NTFS permission. The user obtains an error message, stating that access has been denied.
The first step is to collect information on what effective rights the user has to this resource. The appropriate steps are documented as follows:
E:\>cacls Secure Directory
E:\Secure Directory DISC-WORLD\Domain Guests:(OI)(IO)N
DISC-WORLD\Domain Guests:(CI)N
DISC-WORLD\Domain Users:(OI)(IO)C
DISC-WORLD\Domain Users:(CI)C
DISC-WORLD\wayne:(OI)(IO)F
DISC-WORLD\wayne:(CI)F
DISC-WORLD\Domain Admins:(OI)(IO)C
DISC-WORLD\Domain Admins:(CI)C
Everyone:(OI)(IO)(special access:)
GENERIC_READ
GENERIC_EXECUTE
Everyone:(CI)R
E:\>cacls Secure Directory\*.*
Access is denied.
E:\>whoami
DISC-WORLD\TestUser
It's possible to use a utility named IFMEMBER.EXE, supplied with the Windows 4.0 NT Resource Kit, which determines whether or not a user belongs to a group. The syntax of this utility is:
ifmember [groupname1] [groupname2 ...] [groupnameN]
The mystery is solved, however, when it becomes obvious that TestUser is a member of the global group Domain Guests and that this group has been assigned No Access to the specified resource (E:\Secure Directory). The solution lies in removing the user from the offending group or explaining to the user why he's not obtaining permission to access this specific resource.
Reacting to a situation in the security environment is not always desirable--that is, waiting for the user to bring a security problem to the attention of an administrator. Being proactive about security problems is often desirable, however, especially in high-risk environments in which security breaches can be costly.
To this end, Windows NT 4.0 provides a significant degree of security auditing, which enables the administrator to track specific security events. Auditing is discussed in the "Auditing User Activity" section earlier in this chapter. After auditing has been enabled, the administrator must monitor the Event Viewer (Security Log) for possible signs of problems or security breaches.
© Copyright, Macmillan Computer Publishing. All rights reserved.