Asp. NET identity Simulation

asp.net when using impersonation, the ASP.net application can choose to execute as the customer for which these applications are currently operating. This is usually done in order to avoid handling authentication and authorization issues in ASP.net application code. Instead, you rely on Microsoft Internet Information Services (IIS) to authenticate users, then pass authenticated tokens to the ASP.net application, or pass unauthenticated tags if the user cannot be authenticated. In either case, if "impersonation" is enabled, the ASP.net application simulates any markup that is received. The asp.net application of the current impersonated customer relies on the settings in the NTFS directory and file to allow the client to gain access or deny access. Be sure to format the server file space as NTFS so that you can set access permissions.

Impersonation is disabled by default. For ASP compatibility, the user must explicitly enable impersonation. If impersonation is enabled for a given application, ASP.net always simulates the access token that IIS provides to the ISAPI extension. The tag can be either a validated user tag or an anonymous user's token (such as IUSR_machinename). Impersonation occurs regardless of the type of authentication used in the application.

Only the application code can be emulated, compiled and configured to read as a process tag. The results of the compilation are placed in the "temporary asp.net files" directory. The impersonated account requires read/write access to the directory. If the application is on a universal naming convention (UNC) share, asp.net will always impersonate the tag provided to IIS to access the share unless the configuration account is used. If an explicitly configured account is provided, ASP.net will use the account instead of the IIS UNC flag. It is true that applications that require impersonation based on each request can be configured directly to simulate the user submitting the request.

By default, impersonation is disabled at the machine level. And unless overridden, all application domains inherit this setting. You can enable impersonation by placing the configuration file in the application root directory. For more information about the ASP.net configuration system, see ASP.net configuration.

This instruction is layered, as is the case with other configuration directives. Unless explicitly overridden, nested programs in the hierarchy will comply with it. The default values for this setting are shown below.

<impersonation enable= "false"/>

The minimal configuration file that enables impersonation for an application may look similar to the following example.

<!--web.config file. -->
<identity impersonate= "true"/>

There is also name support for running the application in a configurable capacity. For example:

<identity impersonate= "true" Username= "Contoso\jane" password= "Pass"/>

This will allow the entire application to run in Contoso\jane, regardless of the identity of the request, as long as the password is correct. This type of impersonation can be delegated to another computer.

You can programmatically read the identity of the impersonated user, as shown in the following example.

[Visual Basic]
Dim username as String = System.Security.Principal.WindowsIdentity.GetCurrent (). Name

[C #]
String username = System.Security.Principal.WindowsIdentity.GetCurrent (). Name;

In the example above, userName and password are stored in clear text in the configuration file. Although IIS does not transfer the. config file to respond to user agent requests, it can read the configuration file in other ways, such as by authenticated users with the appropriate credentials on the domain containing the server. For enhanced security, the identity section supports storing encrypted userName and password properties in the registry, as shown in the following example.

Username= "Registry:hklm\software\aspnetidentity,name"
Password= "Registry:hklm\software\aspnetidentity,password"

The part of the string that precedes the keyword registry and the comma represents the name of the ASP.net open registry key. The section after the comma contains the name of a string value that asp.net the credentials from this name. Must have a comma, and the credentials must be stored in the HKLM hive. If the configuration is malformed, ASP.net does not start the worker process, and then displays the code path that caused the current account creation to fail.

The credentials must be in REG_BINARY format and contain the output of the Windows API function CryptProtectData call. You can use the ASP.net Settings Registry console Application (Aspnet_setreg.exe) to create encrypted credentials and store them in the registry. The application uses CryptProtectData to complete the encryption. To download aspnet_setreg.exe with your Visual C + + source code and documentation, visit the WEB site www.asp.net and search for "aspnet_setreg."

The access rights for the keys that store the encrypted credentials should be configured to provide access only to Administrators and SYSTEM. Because the key is read by the ASP.net process running as SYSTEM, the following permissions should be set:

Administrators:f
System:f
CREATOR owner:f
Processaccount:r
This provides two lines of defense to protect the data:

ACL permissions require that the identity of the Access data be administrator.
An attacker would have to run code (CRYPTUNPROTECTDATA) on the server to recover the credentials of the account.