|
ASP.NET Permissions | |
|
||
|
Home « Computers « DevBlog | |
Back to: Development Blog Contents
Making ASP.NET applications run in production environments and in development debugging mode as a non-Admin is a real challenge.
There are countless articles and complaints on the Internet about how to get ASP.NET applications running with the correct permissions. Part of the problem lies with deploying apps into live environments and the remaining part sits with developers who want to develop using a non-Admin account (see my Developing as Non-Admin blog entry).
Deploying ASP.NET Apps
In mid 2005 we had to deploy a large ASP.NET app onto a Windows 2003 Server Standard Edition and a Small Business Server 2003 Edition. Only through a jumble of clues and detective work was it possible to get the app to run successfully. I should point out that the app was deployed as a debug build, as it was brand new and it was vital to collect debugging information in the case of an unexpected crash in the first release. The debugging release seems to have created extra demands to expand the permissions to allow it to run in a live environment, thereby complicating this whole issue.
If you are running IIS on a Domain Controller, see KB article Q315158 for details about how it is necessary to create a domain user account and assign that in machine.config. This article does not explain the permission requirements.
On SBS 2003 it was necessary to add the special domain user to the IIS_WPG group and then give the group permissions to the following folders:
C:\WINNT\TEMP
C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files
C:\Document and Settings\LocalService\Local Settings\Application Data
The last folder was only found by running filemon.exe during failure, saving the log file to disk, then searching through the file for the word DENIED to reveal which accounts were failing to open files.
In Windows 2003 Server Standard Edition without a domain controller the permission requirements were subtly different, and some of the folder structure differs from SBS 2003. I have not recorded the differences, but once again, the filemon.exe log was a vital tool to reveal the failing file permissions.
Debugging ASP.NET Non-Admin
As mentioned in the Developing as Non-Admin entry, in Ausgust 2005 I converted to developing under a non-Admin account. Only minor problems occured at first, until a few days later I hit F5 in Visual Studio to run an ASP.NET project in debug mode and get this:
Error while trying to run project:
Unable to start debugging on the web server. Access is denied.
Filemon tells me that my user account is failing to access C:\windows\system32\cmd.exe, which gives no clue as to what pemissions are missing. Google searches lead me to post the following rather depressing message into the developer forum:
My reading so far indicates that debugging managed code in the ASP.NET process is not possible unless you are a member of the Administrators group. Q893658 and Q891027 lead to more links on this subject as well as a gotodotnet DOC file which says: You may be the member of “Debugger users” group, but you don’t have the right to debug the aspnet worker process, because you are not the “aspnet” user account or the member of “Administrators” group. Please add your user account to the “Administrators” group on the machine. Deeptanshu’s blog quotes: I just have read an article in a local dotNet magazin (www.dotnetpro.de) that it is impossible to debug an ASP.NET application if you develop within a normal user account. As stated in the article the problem is that the ASP.NET worker process is creating some special NT-events that will be used for communication and those events will be created with NULL as parameter for the security settings. So as NULL means take the security token from the process running that results in the events being accessible only from the ASP.NET User and any administrators of the machine (as administrators have the system privilege to debug other user's processes). |
In a stroke of brilliance, Minas from the forum suggests the following:
>Try this:
> Go into services - IIS
> machine.config - process model
>& set both of them to your own account...
This sounds reasonable, so I just have to trick IIS into running as me, then I can debug it because we are the same person! This is highly irregular, but on a development PC devoted to one person it's quite reasonable. It eventually works, as described in this reply:
Minas, that was today’s Top Gun manoeuvre of lateral thinking. I gave it my best shot, and after more than an hour of heartbreak and frustration I have finally got ASP.NET running and debugging as a non-Admin. It’s a bit odd to run ASP.NET as me, but since it’s my personal development machine, who cares, so long as it works. I put my name and password in the processModel. Filemon indicated access to the following folders was failing (so I simply set them to read/write): C:\WINDOWS\system32\ A reboot was required after changing the permissions. It’s finally working. Well done. |
The key to this solution was created my special experimental group called 'ASP Power' that contained every account that I thought might have been involved in the lack of permissions. In the end it contained ASPNET, greg, IUSR_xxx, IWAM_xxx and NETWORK SERVICE. Some of these might be overkill, but I haven't had time to incrementally remove the accounts to find the minimum necessary configuration.
Back to: Development Blog Contents