Introduction

Impersonation in .NET means temporarily running code under another Windows identity so that filesystem, network, or registry access happens with that user’s permissions. The important boundary is that this is fundamentally a Windows concept, and modern .NET code usually uses WindowsIdentity.RunImpersonated rather than older thread-level APIs.

Use WindowsIdentity.RunImpersonated

In current .NET, the preferred pattern is to obtain a Windows access token and execute a delegate under that identity.

1using System;
2using System.Runtime.InteropServices;
3using Microsoft.Win32.SafeHandles;
4using System.Security.Principal;
5
6class Program
7{
8    [DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
9    static extern bool LogonUser(
10        string username,
11        string domain,
12        string password,
13        int logonType,
14        int logonProvider,
15        out SafeAccessTokenHandle token);
16
17    static void Main()
18    {
19        if (!LogonUser("username", "DOMAIN", "password", 2, 0, out var token))
20            throw new InvalidOperationException("Logon failed.");
21
22        WindowsIdentity.RunImpersonated(token, () =>
23        {
24            Console.WriteLine(WindowsIdentity.GetCurrent().Name);
25            // access protected resource here
26        });
27    }
28}

This keeps the impersonation scope explicit and limited to the delegate.

Why Scoped Impersonation Is Better

Older .NET code often used WindowsImpersonationContext and manually reverted the context later. That works in legacy code, but scoped execution is safer because it makes the impersonation boundary obvious and reduces the chance of accidentally continuing under the wrong identity.

That matters most in server code, where leaked impersonation state can become a security bug instead of only a maintenance issue.

Typical Use Cases

Impersonation is often used when an application must:

• read or write a protected network share,
• execute a Windows-only administrative action,
• access resources as a domain user instead of the service account.

The pattern is less about changing who the application "is" globally and more about running one sensitive operation under the correct identity.

Security Considerations Matter More Than the API Call

The hardest part of impersonation is usually not the code. It is credential handling, token acquisition, and minimizing the scope of privileged work. Hard-coding passwords is a bad operational pattern even if the impersonation code itself is technically correct.

A good design keeps credentials in secure storage, limits the impersonated block, and reverts immediately after the necessary operation completes.

Platform Boundary

This topic is Windows-specific. If your application runs cross-platform, impersonation may not make sense as a portable feature. In that case, the right design is often explicit service credentials or platform-specific adapters rather than assuming one identity model everywhere.

Revert Automatically by Keeping the Scope Small

One reason RunImpersonated is attractive is that control returns to the original identity when the delegate finishes. That automatic boundary is easier to audit than code that manually enters and exits impersonation state across several methods. In security-sensitive code, explicit boundaries are part of the solution, not just a convenience feature.

Common Pitfalls

• Using legacy impersonation patterns when a scoped modern API is available.
• Expanding the impersonated block far beyond the one operation that needs it.
• Hard-coding credentials directly in source code.
• Forgetting that impersonation is a Windows-specific feature, not a general .NET abstraction.
• Treating impersonation as an authentication substitute instead of a carefully scoped authorization tool.

Summary

• Modern .NET impersonation typically uses WindowsIdentity.RunImpersonated.
• Impersonation should be scoped tightly around the operation that needs alternate permissions.
• The real complexity is credential and token handling, not only the API surface.
• Legacy context-based approaches still exist but are less explicit and easier to misuse.
• This is fundamentally a Windows capability, so platform assumptions matter.
• Small API choices can carry significant semantic meaning.