Programming Microsoft ASP.NET 4 - Dino Esposito [409]
Impersonating a fixed identity is different from classic, per-request impersonation such as impersonating the identity of the Windows user making the request. Per-request impersonation refers to the situation in which you enable impersonation without specifying a fixed identity. In this case, the security token with identity information is created by IIS and inherited by the worker process. When a fixed identity is involved, the security token must be generated by the ASP.NET worker process. When running under a poorly privileged account, though, the ASP.NET worker process sometimes lacks the permission to do that.
Impersonating Through the Anonymous Account
A third possibility to change the identity of the ASP.NET worker process is by impersonating through the anonymous account. The idea is that the ASP.NET application grants access to anonymous users, and the anonymous account is configured 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 NETWORK SERVICE or the virtual account, which means you don’t have to worry about replicating into the new account the minimum set of permissions on folders that allow ASP.NET to work.
Privileges of the ASP.NET Default Account
Of all the possible user rights assignments, ASPNET and NETWORK SERVICE are granted only the following five:
Access this computer from the network
Deny logon locally
Deny logon through Terminal Services
Log on as a batch job
Log on as a service
In addition, the accounts are given some NTFS permissions to oper ate on certain folders and create temporary files and assemblies. The folders involved are these:
.NET Framework Root Folder This folder contains some .NET Framework system assemblies that ASP.NET must be able to access. The physical folder is normally Microsoft.NET\Framework\[version] and is located under the Windows folder. ASP.NET has only read and list permissions on this folder.
Temporary ASP.NET Files This folder represents the file system subtree in which all temporary files are generated. ASP.NET is granted full control over the entire subtree.
Global Assembly Cache ASP.NET needs to gain read permissions on the assemblies in the global assembly cache (GAC). The GAC is located in the Windows\Assembly\GAC folder. The GAC folder is not visible in Windows Explorer, but you can view the installed assemblies by opening the Windows\Assembly folder.
Windows System Folder The ASP.NET process needs to access and read the System32 Windows folder to load any necessary Win32 DLLs.
Application Root Folder The ASP.NET process needs to access and read the files that make up the Web application. The folder is typically located under Inetpub\wwwroot.
Web Site Root ASP.NET might have the need to scan the root of the Web server—typically, Inetpub\wwwroot—looking for configuration files to read.
An ASP.NET application running under an account that lacks some of these permissions might fail. Granting at least all these permissions is highly recommended for all accounts used for fixed-account impersonation.
The Trust Level of ASP.NET Applications
ASP.NET applications are made of managed code and run inside the common language runtime (CLR). In the CLR, running code is assigned to a security zone based on the evidence it provides about its origin—for example, the originating URL. Each security zone corresponds to a set of permissions. Each set of permissions corresponds to a trust level. By default, ASP.NET applications run from the MyComputer zone with full trust. Is this default setting just evil?
An ASP.NET application runs on the Web server and doesn’t hurt the user that connects to it via the browser. An ASP.NET application cannot be consumed in ways other than through the browser. So why do some people