Impersonation enables ASP.NET to execute code and access resources in the context of an authenticated and authorized user, but only on the server where ASP.NET is running. To access resources located on another computer on behalf of an impersonated user requires authentication delegation (or delegation for short). You can think of delegation as a more powerful form of impersonation, as it enables impersonation across a network. For more information, see ASP.NET Impersonation.
For delegation to work, ASP.NET must be able to authenticate against the remote server using the credentials of the client you wish to delegate. However, there are numerous factors that determine if delegation can occur, such as Internet Information Services (IIS) authentication scheme, ASP.NET process identity, and the operating systems of the machines involved.
Misuse of delegation could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.
On Windows 2000, the following authentication schemes impact delegation of impersonated clients as follows:
When using impersonation with an anonymous client, ASP.NET impersonates the account specified by IIS for anonymous access. By default, this is the IUSR_machinename account with a password controlled by IIS, which cannot be delegated.
However, if IIS is configured to use a local account that is identical (including password) to a local account on the remote machine, delegation is possible. In addition, if IIS is configured to use a domain account that has access to the remote machine, delegation is also possible.
When using Basic authentication, delegation is possible if the account is a local account that is identical (including password) to a local account on the remote machine. In addition, delegation is also possible if the account is a domain account that has access to the remote machine.
Digest authentication does not permit delegation since IIS does not posses any credentials for the client with which to authenticate against the remote machine.
Integrated Windows Authentication
When Internet Explorer attempts to access a protected resource, IIS sends two WWW-Authenticate headers to the browser, Negotiate and NTLM. The Negotiate header is only sent by IIS running on Windows 2000 or later. This header indicates that IIS supports the Negotiate protocol, which enables a negotiation to occur between Internet Explorer and IIS on whether to use Kerberos or NTLM authentication. IIS uses Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 or later, and both are members of the same domain or trusted domains. Otherwise, the server defaults to using NTLM.
Since NTLM authenticates the user for IIS without providing the user's credentials to IIS, IIS cannot delegate that user's credentials to a remote machine.
When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 or later that are trusted and configured for delegation.
Client Certificate Mapping
Client Certificate Mapping supports delegation in some instances. That is, if you use IIS mapping (many-to-one) and the mapped account is identical (including password) to a local account on the remote machine, delegation is possible. In addition, delegation is possible if IIS maps the certificate to a domain account that has access to the remote machine. In both cases IIS stores credentials for the account in question.
However, if using Active Directory mapping (one-to-one), delegation is not possible. This is because Active Directory holds the certificate for each account, not IIS.
ASP.NET Process Identity
If impersonation is not configured for an ASP.NET application, the ASP.NET process identity determines which account to use for delegation when accessing remote machines as follows:
<processModel userName="machine">, which is the default setting, ASP.NET attempts to delegate the ASPNET local user account. As this account does not possess any network credentials, to the network it appears as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON).
Note You should not confuse the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON) with the anonymous access account used by IIS to provide anonymous Web access (IUSR_machinename). The Windows anonymous account is used by the operating system when an identity cannot be authenticated.
<processModel userName="SYSTEM">, ASP.NET attempts to delegate the account used for running IIS, which by default is the LocalSystem account (NT AUTHORITY\SYSTEM). Starting with Windows 2000, this account possesses the network credentials associated with the machine account in the domain of which it is a member (domainname\machinename).
When you configure
<processModel> to use a particular account as the process identity, ASP.NET attempts to delegate that account. If it is a local account that is identical (including password) to a local account on a remote machine, delegation is possible. If such an account does not exist on the remote machine, to the network it appears as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON). In addition, delegation is also possible if the account is a domain account that has access to the remote machine, in which case it uses the domain network identity of that account.
In Internet Information Services (IIS) 6.0, the default identity is the NetworkService account. It behaves the same as the System account. This account possesses the network credentials associated with the machine account (domainname\machinename) in the domain of which it is a member.
There are several methods for accessing remote resources when you cannot delegate using your chosen authentication scheme, such as:
- Create a serviced component that accesses the remote resource using a configured identity, and then access that component from ASP.NET. For more information, see Serviced Component Overview.
- Call the LogonUser platform API to create a logon session that you can impersonate to access the remote resource. The LogonUser platform API requires the SE_TCB_NAME privilege (the "Act as part of the operating system" privilege) on Windows 2000 but not on Windows XP and later. For more information, see WindowsIdentity.Impersonate Method.
- Use a null session share, which enables anonymous access to UNC shares. For more information, see "HOW TO: Enable Null Session Shares on a Windows 2000-Based Computer (Q289655)" on the Microsoft Knowledge Base Web site (http://support.microsoft.com/default.aspx?scid=kb;EN-US;q289655).
Security Note Using null session shares to grant access to a shared resource is not a recommended practice. It is mentioned here to recognize this capability and to warn against its use. If you configure a shared resource in this manner, the resource is not secure as it grants access to anyone requesting it.