Friday, August 21, 2009

ASP.NET File Permissions

Short Story:

Use Process Monitor to help resolve ASP.NET file permission problems.

Long Story:

I have some files on one machine that I would like to make available through one of our company websites. We use IIS for our hosting, so I created a file share on the machine with the files and linked to it using a Virtual Directory. Now when resources are accessed via IIS they do so as the IUSR account (unless other authentication options are enabled), so I added read permissions for this user to my files security settings and to the sharing permissions (I always forget to do both), but it did not work. There may be some fancy ASP logging that tells you why, but I have always struggled to get the ASP logs to do anything very useful. Several smart people on the Internet recommended using Process Monitor from Microsoft (previously from Sysinternals). Everything that the Sysinternals guys make is made of pure awesome, and this is no exception. It allows you to search for the ACCESS DENIED operation (a CreateFile function call), and this shows all of the relevant details, including the user credentials used. In my case it was IUSR, or actually /IUSR_, which is some sort of domain equivalent. Exactly the user I had set the permissions for, so why wasn't it working?

Running Process Monitor on the file hosting machine instead reveals the problem: the file access was impersonating a different user, namely /$. It seems that this is the default behaviour across machine boundaries unless you are explicitly impersonating a designated user, in which case those credentials are passed intact.

The fix I chose may not be the recommended solution, but it worked for me: explictly impersonate IUSR to force the credentials to be passed across the machine boundary. To do this you need the IUSR password, which can be obtained by following this helpful advice. Whatever you do, don't change the IUSR password or you may unwittingly open a portal to a new dimension of pain.

2 comments:

richardgaywood said...

Of course, now, if you web server is rooted, you potentially have an entire compromised network rather than just one server to clean up...

Rupert said...

Agreed. Every connection like this will multiply your risk, not least because you now have two machines to regularly patch.

A single internet-facing machine is always going to be the most secure option. I would have physically mounted the drive there instead, but I ran out of SATA ports :-)