Access Control
Access Control |
|
Impersonation is the ability of a thread to execute in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client's security context, a service "is" the client, to some degree. One of the service's threads uses an access token representing the client's credentials to obtain access to the objects to which the client has access.
The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do. For example, suppose a file server has files containing confidential information, and each of these files is protected by a DACL. To prevent a client from obtaining unauthorized access to information in these files, the service can impersonate the client before accessing the files.
Every process has a primary token that describes the security context of the user account associated with the process. The user associated with the process for an ordinary application is the human user who started the application. This is not the case for a service process. Services run under their own accounts and act as users in their own right. System services installed with the operating system run under the Local System account. Other services can be configured to run under this account, or they can be given separate accounts on the local system or in Active Directory. For information about installing and configuring domain services, see "Service Publication in Active Directory" in this book.
The primary token for a service is associated with the control thread in the service process and with all other threads acting on behalf of the service. It identifies the service's account, that account's groups, and its privileges. This information is used during access checks when the service requests access to objects needed for its own housekeeping.
When a service accepts a client, it creates a thread to do the work and associates the client's access token with the worker thread. The client's access token is known as an impersonation token. The impersonation token identifies the client, the client's groups, and the client's privileges. This information is used during access checks when the thread requests access to resources on the client's behalf. When impersonation is over, the thread reverts to using the primary token and returns to operating in the service's own security context rather than the client's.
The mechanism for impersonation is illustrated in Figure 12.8.
Figure 12.8 The Roles of a Service's Primary and Impersonation Tokens
If impersonation succeeds, it means that the client has agreed to let the server "be" the client to some degree. A client process can control to what extent a service is able to act as the client by selecting an impersonation level when it connects to the service. By choosing an impersonation level, the client tells the service how far it can go in impersonating the client.
An impersonation level cannot be selected by users. It is specified as Security Quality of Service (SQoS) information in the code for client/server applications. There are four levels: anonymous, identify, impersonate, and delegate. The anonymous level has never been supported. Prior to Windows 2000, the only levels supported were identify and impersonate. Windows 2000 adds support for delegate.
The following is a brief description of each level:
Anonymous The client is anonymous to the service. The service can impersonate the client but the impersonation token does not contain any information about the client.
Identify The service can get the identity of the client and use this information in its own security mechanism, but it cannot impersonate the client.
Impersonate The service can impersonate the client. If the service is on the same computer as the client process, it can access network resources as the client. If the service is on a remote computer, it can impersonate the client only when accessing resources on the service's computer.
Delegate The service can impersonate the client not only when it accesses resources on the service's computer but also when it accesses resources on other computers. This level is supported only in Windows 2000 and later versions of the operating system.
Impersonation works at the delegate level only under the following conditions:
To configure a user account for delegation, right-click the User object in Active Directory Users and Computers, click Properties, and then click the Account tab. In the Account options box, look for the Account is sensitive and cannot be delegated option. Make sure this option is not selected. Figure 12.9 shows the correct setting.
Figure 12.9 User Authentication Can Be Delegated
The way you configure the service account depends on whether the service runs under the Local System account on a computer or under its own domain user account. If the service is configured to run under the Local System account, the computer where the service runs must be trusted for delegation. To configure a computer account as trusted for delegation, you must have the Enable computer and user accounts to be trusted for delegation privilege on the computer. If you have this privilege, right-click the Computer object in Active Directory Users and Computers, click Properties, and then click the General tab. Check the box marked Trust computer for delegation. Figure 12.10 shows the correct setting.
Figure 12.10 Computer Account Trusted to Act as a Delegate
Warning
When you trust a computer for delegation, you enable delegation for all services that run under the Local System account on the computer. If an unwary administrator installs an untrusted service on the computer and configures it to run as Local System, it too can access network resources while impersonating other users. A better practice is to configure services that use delegation to run under their own domain user accounts managed by domain administrators.
If the service is configured to run under its own domain user account, the service's user account must be enabled to act as a delegate. To configure a service's user account, right-click the User object, select Properties, and then click the Account tab. In the Account options box, select the Account is trusted for delegation option. Figure 12.11 shows the correct setting.
Figure 12.11 Service User Account Trusted to Act as a Delegate
