If you are like many systems administrators, you are probably scrambling to figure out how to best accommodate the growing number of .NET developers without compromising security and availability. If you are like most developers I know, you are frustrated with system administrators dragging their feet while you sit around missing out on an exciting and powerful technology. I may be biased, but I must say that the infrastructure teams are correct to delay just a bit. The .NET Framework is a new and remarkable accomplishment for Microsoft, but there are many things to consider before you just run the install and start deploying code.
One of the first things that you should notice after installing the .NET Framework and running some test pages is the ASP.NET worker process. This task runs as aspnet_wp.exe if viewed in the Windows Task Manager. The identity of this process is set in the Machine.Config file found in the "CONFIG" subfolder of your .NET Framework install directory (c:\WINNT\Microsoft.NET\Framework\{Version Number}\CONFIG on Windows 2000 installations). The default account for the ASP.Net worker process is a local account "ASPNET". This may vary for some users as this does not hold true for all OS configurations or versions of the .Net Framework.
This account is most similar to the IWAM_MachineName account used by IIS. While this account is typically harmless, there is still an inherent lack of administrative control.
There are options other than the default installation
accounts. If you are in an environment with a Windows NT or Windows 2000 domain, you may use a domain account for your ASP.NET worker process. This would allow more control over what the executing code does and does not have access to. In the environment I manage, this proves valuable because local machine accounts do not have any level of access to network resources, such as DFS shares. In addition to the access controls, there is another positive with Windows 2000 installations.
In the Web.Config file -- present in each .NET Web application -- the developer has the option to specify an impersonation identity. While this may be a necessary evil for some applications, it only further exposes the system in a majority of situations. Users could then set code to impersonate personal or other user accounts, thus exposing your systems to risks beyond your control. When a domain account is configured in the Machine.Config file, the impersonation user in the Web.Config file is rendered inoperable.
If this sounds appealing, please follow these steps to configure the ASP.NET worker process identity:
- Choose an account.
- Make a backup of your current Machine.Config file.
- Locate the section titled "processModel" in the tag.
- Modify the username and Password attributes. Make sure you include the domain\username when appropriate.
- Save your changes.
- Read/write access is required to the %installroot%\ASP.NET Temporary Files directory. Subdirectories beneath this root are used for dynamically compiled output.
- Read/write access is required to the %temp% directory, which is used by the compilers during dynamic compilation.
- Read access is required to the application directory. (Web site home directory)
- Read access is required to the %installroot% hierarchy to make it possible to access to system assemblies.
- Restart IIS
Here is a sample of the batch file that I use:
cacls "C:\WINNT\Microsoft.NET" /T /E /C /P domain\account:R
cacls "C:\WINNT\Microsoft.NET\Framework\v1.0.3705\Temporary ASP.NET Files" /T /E /C /P domain\account:C
cacls "C:\WINNT\temp" /T /E /C /P domain\account:C
cacls "C:\inetpub\wwwroot" /T /E /C /P domain\account:R
cacls "d:\websites" /T /E /C /P domain\account:R
cacls "C:\WINNT\assembly" /T /E /C /P domain\account:R
Of course you should run test code after making these changes to verify that ASP.NET is still able to execute. I have seen some instances where using a domain account on a domain controller did not work. It is generally best practice to avoid running production Web applications on a domain controller in most environments. If you are having problems, please check the Event Log for errors specific to insufficient permissions when starting the ASP.NET worker process.
Finally, there are a few other key attributes to notice when reviewing the processModel attribute of the Machine.Config file. They include timeout, requestLimit, memoryLimit, and ClientConnectedCheck. Although the .NET Framework and ASP.NET worker process are generally stable, limiting the time a process runs without restarting and controlling the maximum memory consumable by the process can go a long way to safeguard against disruptive code. These attributes should be modified to better suit your environments and the needs of your user community. You may even want to write a script utilizing the XML document object model to automatically set these attributes when you deploy the Framework. More information on the processModel attribute of System.Web can be found on Microsoft's Web site. The current link is http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfprocessmodelsection.asp.
About the Author
Christopher Spann has been supporting Web servers in ISP, Web hosting, and corporate environments since 1994. He's spent the last two years supporting over 200 Web and application servers for a major corporation. He is also profficient in ASP.NET, classic ASP, VB .NET, VB, and COM+.
Christopher has an MIS degree from the University of Houston and plans on attending law school there this fall. He can be reached at cspann7@yahoo.com.
