Impersonation | Improving Web Application Security: Threats and Countermeasures

By default, ASP.NET applications do not impersonate. The security context of the ASP.NET worker process account (ASPNET by default) is used when your application accesses Windows resources.

<identity>

The <identity> element is used to enable impersonation. You can impersonate:
The original caller (the IIS authenticated identity)
A fixed identity

Impersonating the Original Caller

To impersonate the original caller, use the following configuration:

 <identity impersonate="true" />

The impersonation uses the access token provided by IIS that represents the authenticated caller. This may be the anonymous Internet user account, for example, if your application uses Forms authentication, or it may be a Windows account that represents the original caller, if your application uses Windows authentication.

If you do enable original caller impersonation, note the following issues:

Application scalability is reduced because database connections cannot be effectively pooled.
Administration effort increases as ACLs on back-end resources need to be configured for individual users.
Delegation requires Kerberos authentication and a suitably configured Windows 2000 environment.

For more information, see "How To: Implement Kerberos Delegation for Windows 2000" in the "How To" section of "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication " at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT05.asp .

Impersonating a Fixed Identity

To impersonate a fixed identity, specify the identity using the userName and password attributes on the <identity> element:

 <identity impersonate="true" userName="MyServiceAccount"                              password="Str0ng!Passw0rd"/>

Do not store credentials in plaintext as shown here. Instead, use the Aspnet_setreg.exe tool to encrypt the credentials and store them in the registry.

Task To encrypt credentials for <identity>

Run the following command from the command prompt:
```
 aspnet_setreg -k:Software\YourApp\identity -u:CustomAccount :p:StrongPassword 
```
This stores the encrypted credentials in the specified registry key and secures the registry key with a restricted ACL that grants Full Control to System, Administrators, and Creator Owner.

Reconfigure the <identity> element and add the following userName and password attributes.

 <identity impersonate="true" userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>

Use Regedt32.exe to create an ACL on the above registry key that grants read access to the ASP.NET process account.

For more information, see Microsoft Knowledge Base article 329290, "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings."

Act as Part of the Operating System

The ASP.NET version 1.0 process account requires the "Act as part of the operating system" user right on Windows 2000 when you impersonate a fixed identity by specifying userName and password attributes. Because this effectively elevates the ASP.NET process account to a privilege level approaching the local System account, impersonating a fixed identity is not recommended with ASP.NET version 1.0.

Note	If you are running ASP.NET version 1.1 on Windows 2000 or Windows 2003 Server, this user right is not required.

NTFS Permission Requirements

NTFS permissions must be appropriately configured for impersonation identities. For more information, see "NTFS Permission Requirements" later in this chapter.