Impersonate a client after authentication
Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8
This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting.
Reference
This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to administrative or system levels.)
Impersonation is the ability of a thread to run 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.
Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started.
This policy setting is supported on versions of Windows that are designated in the Applies To list at the beginning of this topic.
Constant: SeImpersonatePrivilege
Possible values
User-defined list of accounts
Default values
Not defined
Best practices
A user can impersonate an access token if any of the following conditions exist:
The access token that is being impersonated is for this user.
The user in this session logged on to the network with explicit credentials to create the access token.
The requested level is less than Impersonate, such as Anonymous or Identify.
Because of these factors, users do not usually need to have this user right assigned.
Location
GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Default values
By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and stand-alone servers.
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
Server type or GPO |
Default value |
|---|---|
Default Domain Policy |
Not eefined |
Default Domain Controller Policy |
Administrators Local Service Network Service Service |
Stand-Alone Server Default Settings |
Administrators Local Service Network Service Service |
Domain Controller Effective Default Settings |
Administrators Local Service Network Service Service |
Member Server Effective Default Settings |
Administrators Local Service Network Service Service |
Client Computer Effective Default Settings |
Administrators Local Service Network Service Service |
Operating system version differences
There are no differences in the way this policy setting works between the supported versions of Windows that are designated in the Applies To list at the beginning of this topic.
Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
Local policy settings
Site policy settings
Domain policy settings
OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
Vulnerability
An attacker with the Impersonate a client after authentication user right could create a service, mislead a client into connecting to the service, and then impersonate that computer to elevate the attacker's level of access to that of the computer.
Countermeasure
On member servers, ensure that only the Administrators and Service groups (Local Service, Network Service, and Service) have the Impersonate a client after authentication user right assigned to them.
Potential impact
In most cases, this configuration has no impact. If you have installed optional components such as ASP.NET or IIS, you may need to assign the Impersonate a client after authentication user right to additional accounts that are required by those components, such as IUSR_<ComputerName>, IIS_WPG, ASP.NET, or IWAM_<ComputerName>.