The ASP.NET worker process does not run under the almighty SYSTEM account and does not impersonate any identity by default. The process works under a made-to-measure account—ASPNET or NETWORKSERVICE depending on the underlying operating system and process model. Applications can configure the worker process account through the <processModel> section in the machine.config file. The attributes responsible for that are userName and password. Their default settings are as follows:
<processModel userName="machine" password="AutoGenerate" ... />
The user name “machine” is a nickname for the aforementioned ASPNET (or NETWORKSERVICE) account. This built-in account is created when the .NET Framework is installed. The password is autogenerated and stored in the web server’s machine security authority.
The ASP.NET user account can be changed just like any other configuration settings. Notice, though, that the attributes of the <processModel> section cannot be overridden in a web.config file. The section is supported only in the machine.config file, and changes are not applied until IIS is restarted.
In a situation where you want to change the default ASP.NET account to give it more or fewer privileges, how should you proceed? Is it preferable to create a custom account and use it for the worker process (via the <processModel> section) or should you force the ASP.NET worker to impersonate a given identity through the <identity> section?
Using the <processModel> section is the only way to change the real identity of the ASP.NET process. You do this using the following setting:
<processModel userName="..." password="..." />
If you set the process identity in the <processModel> section, then all threads in the process will use this as the base identity and no extra work is needed on thread switches. (The advantage in performance is indisputable but not a big win for an application.) If you change the process account, it is more important that you grant the new account at least full permissions in the Temporary ASP.NET Files folder. Better yet, carefully review the minimum list of privileges required by the ASPNET account and duplicate them.
Alternatively, you could require the worker process to impersonate a fixed identity to serve the request while maintaining the predefined account. Notice that the identity is tied to the process for the whole lifetime, while impersonations come and go and can be reverted, too. Unlike <processModel>, the <identity> section can be used on a per-folder basis. This is a common approach when you run multiple web applications on the same machine and need to give them different identities. Application hosting is one of these scenarios.
To impersonate a fixed identity, first define the user account and then add a setting to the web.config file:
<identity impersonate="true" userName="ItsMe" password="TellMeWhatYouThink" />
Impersonating a fixed identity creates potential security risks if the host system runs Windows 2000 Server. Under this operating system, impersonation requires administrative privileges. Impersonation is simply impossible as long as you run under ASPNET. For impersonation to work, you need to switch to a more powerful account-which contradicts the security push of using a weak account as the default.
Other operating systems (Windows XP and Windows Server 2003) don't have this limitation. In ASP.NET 1.1, though, impersonation under Windows 2000 is possible due to a smart trick performed by the worker process.
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].
