Troubleshooting Tips and Tricks
LANGUAGES: C# | VB .NET
TECHNOLOGIES: ASPNET User | Debugging
Meet the Mysterious ASPNET User
Learn what ASPNET is for - and the problems it can cause - and you'll save yourself all kinds of grief.
By Don Kiely
In my last Troubleshooting Tips and Tricks column (Access is NOT Denied!), I discussed some of the common causes for getting an Access is Denied exception in ASP.NET applications.
Another culprit is the elusive ASPNET user.
When you first install .NET on a server, you end up with a local user called ASPNET. The description in the Computer Management applet's Local User and Groups listing is "Account for running ASP.NET Worker process." Microsoft refers to ASPNET as a "weak account," meaning it has the bare minimum permissions you need to run an ASP.NET application. With a weak account, if a hacker cracks the server using a Web application, he can do only limited damage. Conversely, running the worker thread under the local System account - or, heaven forbid, a domain Administrator account - is inviting disaster big time. Then the hacker would have deep permissions to inflict horrible damage throughout your network.
Incidentally, don't mistake ASPNET for the user under which your IIS service runs. You set that user in the Services section of Computer Management. ASPNET is the user under which ASP.NET worker processes run - the aspnet_wp.exe that IIS uses to process ASP.NET pages. You can change the default from ASPNET in the machine.config file, setting the username and password attributes of the <processModel> element. By default, username is MACHINE, which uses ASPNET. And keep in mind that, in general, you can have a maximum of one worker process per server CPU, so this user is shared across all ASP.NET applications on a server.
This all sounds harmless enough - running the ASP.NET worker process with a weak account is good, isn't it? But there are plenty of potential problems here. According to the .NET documentation, whatever user you use must have some minimum permissions:
- Read/write access to the %installroot%\ASP.NET Temporary Files directory. Subdirectories beneath this root are used for dynamically compiled output.
- Read/write access to the %temp% directory, which is used by the compilers during dynamic compilation.
- Read access to the application directory.
- Read access to the %installroot% hierarchy to allow access to system assemblies. (%installroot% is the location of the .NET Framework files, usually something like C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705 for version 1.0.)
This is a pretty short list of required permissions. But the ASPNET user also is assigned to the Users group by default, so depending on the rights members of Users have, ASPNET might actually have some fairly extensive permissions on the server (but only on the server, as it is a local system account).
There are three important things to know about ASPNET :An ASP.NET worker thread runs under ASPNET's permissions by default; ASPNET has very few permissions, unless it inherits some from Windows groups it belongs to, such as Users; and it is a local account.
Therein lies much of the confusion I see on the support forums. In a typical production environment - on a network in a domain - ASPNET has no rights to use any network resources, such as a database server, files on other machines, printers, and so on. It might not even have permissions to any of those things on its home server!
Where this really gets confusing is when some underlying resource bars access to ASPNET, sending its own Access is Denied message. This causes the developer to go off on a wild goose chase, looking at the code trying to figure out why ASP.NET is not letting that code run. Far more often than not, it has nothing to do with the code but everything to do with ASPNET's permissions.
For example, if your application can read from one directory but not another, check on the permissions the Users group has, if ASPNET is still a member of Users. And if you've assigned ASPNET to the Administrators group to get around some gnarly permissions travesty in an application, remove it immediately! It's an easy solution, but easy solutions are never a good solution in security. I personally guarantee that, at some point, running ASP.NET applications with Administrator permissions will make your life miserable.
If you usually ignore the stack trace the default ASP.NET unhandled exception page presents you, you're missing the chance to cut out a lot of debugging work. By examining exactly what the code was doing when the original exception fired, you often can tell immediately where the problem originated, which can lead you to right to the problem. Or perhaps you at least will discover a resource that has its own logs you can use to trap the bug. Which is probably the most common focus of such problems, particularly when accessing databases,.
Don Kiely is senior information architect for Information Insights, a business and technology consultancy in Fairbanks, Alaska. E-mail him at mailto:[email protected].
