Understanding Impersonation in ASP.NET

Introduction

In web applications, it is sometimes useful – or necessary – for a request to run under a different account than the one used by the web server process. This is known as impersonation. Classic ASP and ASP.NET both support impersonation, but they do so in slightly different ways.

In earlier versions of IIS, content such as HTML pages, classic ASP pages, and COM components often ran under built-in accounts like IUSR_machinename (for anonymous access) and IWAM_machinename (for out-of-process applications). ASP.NET added its own process identity and configurable impersonation options on top of this IIS behavior.

IIS anonymous accounts: IUSR and IWAM

When you enable anonymous access in IIS, the server uses a specific Windows account to represent requests that have not been authenticated. By default, this is the IUSR_machinename account. This account is created during IIS installation and is granted access to web content folders as needed.

For classic ASP and COM+ components, another account called IWAM_machinename is often used for out-of-process execution. Together, these built-in accounts let IIS serve static files and execute ASP or COM components without prompting end users for credentials.

The key point is that, with anonymous access enabled, IIS impersonates the IUSR_machinename account when accessing files. Any resource requested by the user must permit that account in its Windows Access Control List (ACL) in order to be served successfully.

Impersonation in ASP.NET

ASP.NET introduced its own process account and a configuration-driven impersonation model. When an ASP.NET application runs without impersonation, requests execute under the ASP.NET process identity (for example, ASPNET on older systems or the application pool identity on newer IIS versions).

When impersonation is enabled, ASP.NET uses a different Windows identity for executing code and accessing resources. That identity can be:

• The IIS anonymous account (for anonymous requests).
• The authenticated user account (for Windows-authenticated requests).
• A specific Windows account that you configure in web.config.

This gives you fine-grained control over which Windows credentials are used for file access, database access (with integrated security), and other resource checks enforced by the operating system.

Configuring impersonation in web.config

Impersonation is configured using the <identity> element under the <system.web> section in web.config. The simplest form enables impersonation using the caller's identity:

<configuration>
  <system.web>
    <identity impersonate="true" />
  </system.web>
</configuration>

In this configuration:

• If anonymous access is enabled in IIS, ASP.NET impersonates the IUSR_machinename account.
• If anonymous access is disabled, the request runs under the authenticated user's Windows account.

You can also impersonate a specific fixed domain or local account. This is useful when your application needs consistent access to protected resources such as file shares or databases with integrated security.

<configuration>
  <system.web>
    <identity impersonate="true"
              userName="DOMAIN\\WebAppUser"
              password="PlainTextOrEncryptedPassword" />
  </system.web>
</configuration>

In production, you should store sensitive credentials securely (for example, using encrypted configuration sections) and grant the impersonated account only the minimum permissions required to do its job.

Behavior matrix: impersonation on vs. off

The original ASP.NET documentation often described impersonation in terms of how IIS authentication and ASP.NET configuration interact. Conceptually, the behavior looks like this:

If impersonation is enabled in ASP.NET:

• With anonymous access enabled in IIS, requests run as IUSR_machinename.
• With anonymous access disabled, requests run as the authenticated user.
• In all cases, access to files and other Windows resources is controlled by the ACLs associated with that impersonated account.

If impersonation is disabled in ASP.NET:

• With anonymous access enabled in IIS, requests run under the ASP.NET process identity (for example, the application pool account).
• With anonymous access disabled, requests still run under the ASP.NET process identity, even though the user may be authenticated at the IIS level.
• Windows ACLs are evaluated against the process account, not the caller's Windows identity.

This is why impersonation and process identity planning are so important for legacy applications that rely on Windows integrated security to access file shares, registry keys, or databases.

Security considerations and best practices

Impersonation is powerful but easy to misuse. It can inadvertently grant users more access than intended or make it harder to reason about which account is touching which resource.

When you work with legacy ASP.NET applications that use impersonation, keep these guidelines in mind:

• Apply the principle of least privilege to any account you impersonate.
• Avoid using high-privilege accounts (such as local administrators) for impersonation.
• Prefer explicit, well-documented impersonation scenarios over implicit behavior that depends on IIS defaults.
• Document which resources require impersonation and why, so future maintainers can simplify or remove it when migrating to modern frameworks.

For new development on modern .NET, consider alternative approaches such as application-level identities, managed service identities, or claims-based authentication instead of Windows impersonation.