By default, per-request impersonation is disabled in ASP.NET, meaning that each request is always served by a thread running under a fixed account. The account is typically ASPNET or NETWORK SERVICE, depending on the underlying operating system. If per-request impersonation is enabled, the worker thread inherits the security token assigned to the request by IIS. Per-request impersonation changes the identity of the thread executing the current request, not the identity of the ASP.NET worker process hosting the serving thread. Per-request impersonation is activated with the following statement in the web.config file:
<identity impersonate="true" />Another form of impersonation is possible in ASP.NET—per-application impersonation. In this case, you still ask the worker thread to impersonate an identity, except that the identity is fixed and hard-coded in the web.config file:
<identity impersonate="true" <br> userName="MyAspNetAccnt" password="ILoveA$p*SinceVer1
Impersonation doesn’t really change the physical identity of the process running ASP.NET. More simply, all threads serving in the context of the ASP.NET worker process will always impersonate a given user for the duration of the application.
When a fixed identity is involved, the security token must be generated by the ASP.NET worker process. Running under a poorly privileged account like NETWORK SERVICE, though, the ASP.NET worker process may, in some cases, lack the permission to do that.
A process running under a nonadministrator account cannot impersonate a specific account on Windows 2000 unless you grant it appropriate privileges. Under Windows 2000, a process requires the “Act As Part Of The Operating System” privilege to impersonate a fixed identity. This is indeed a strong and powerful privilege that nonadministrator process accounts like ASPNET and NETWORK SERVICE are generally not granted for security reasons.
The requirement disappears with Windows XP and Windows Server 2003, which will also make it possible to impersonate a given identity to processes that lack the “Act As Part Of The Operating System” privilege.
In ASP.NET 1.1, though, impersonating a fixed identity is also possible under Windows 2000 machines and IIS 5.0. The ASP.NET 1.1 runtime plays some tricks to revector the call back to the aspnet_isapi.dll module, which is running inside IIS 5.0 and under the SYSTEM account. Basically, the ASP.NET 1.1 ISAPI extension creates the security token and duplicates it in the memory space of the worker process. In this way, ASP.NET 1.1 supports fixed impersonation without requiring the “Act As Part Of The Operating System” privilege on the worker process account.
In the end, expect to have troubles with fixed impersonation only if you’re still running ASP.NET 1.0 applications under Windows 2000. In this case, for the impersonation to work, you need to run your ASP.NET applications under the SYSTEM account, with the security repercussions that this might have.
A third possibility to change the identity of the ASP.NET worker process is impersonating through the IIS anonymous account. The idea is that the ASP.NET application grants access to anonymous users, and the anonymous account is configured in IIS to be the desired account for the application.
In this case, the application uses per-request impersonation and the ASP.NET code executes as the impersonated account. The process account remains set to ASPNET or NETWORK SERVICE. In this way, you don’t have to worry about replicating in the new account the minimum set of permissions on folders that allow ASP.NET to work.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
