views:

339

answers:

3

Hi all,

at work I am struggling a bit with the following situation: We have a web application that runs on a WIndows Server 2008 64 bits machine. The app's ApplicationPool is running under the ApplicationPoolIdentity and configured for .net 2 and Classic pipeline mode.

This works fine up to the moment that XmlSerialization requires creation of Serializer assemblies where MEF is being used to create a collection of knowntypes.

To remedy this I was hoping that granting the ApplicationPoolIdentity rights to the ASP.Net Temporary Files directory would be enough, but alas...

What I did was the run the following command from a cmd prompt:

icacls "c:\windows\microsoft.net\framework64\v2.0.50727\Temporary ASP.NET Files" /grant "IIS AppPool\MyAppPool":(M)

Obviously this did not work, otherwise you would not be reading this :)

Strange thing is that whenever I grant the Users or even more specific, the Authenticated Users Group those permissions, it works. What's weird as well (in my eyes) is that before I started granting access the ApplicationPoolIdentity was already a member of IIS_IUSRS which does have Modify rights for the temporary asp files directory.

And now I'm left wondering why this situation requires Modify rights for the Authenticated Users group. I thought it could be because the apppool account was missing additional rights (googling for this returned some results, so I tried those), but granting the ApplicationPoolIdentity modification rights to the Windows\Temp directory and/or the application directory itself did not fix it.

For now we have a workaround, but I hate that I don't know what is exactly going on here, so I was hoping any of you guys could shed some light on this.

Thanx in advance!

A: 

What user is the app pool running as? NetworkService? or something else?

Matthew Abbott
The app pool is running under the ApplicationPoolIdentity, that's why access rights were set using icacls in a cmd prompt.
Anton
+1  A: 

If the application pool is running as AppPool Identity then things should work out-of-the box since the worker process will be injected the IIS_IUSRS SID which will have the right permissions to write.

My guess, is that the application must be using Windows authentication and impersonation is enabled in ASP.NET so that code is probably be ran as the specific user that is making the request and not necesarilly the process identity.

Am I right on the guess that the app is running Windows Authentication? and impersonation is enabled in asp.net ?

CarlosAg
Windows authentication is indeed enabled on the app. The app is a servicebus being called from a website that has windows authentication and impersonation set to true, so your guess is dead on. Both the website and the app run under the same AppPool.However, when I run the app from the website myself the problem still exists and I'm member of the local administrators group on the machine that hosts both the website and the service bus app (obviously, it's a development box :p). What am I missing here?
Anton
Even if you are member of the Administrators group you might not be running with Administrator permissions thanks to the Network Token Filtering. I would try ACL'ing specifically for your account and try again (not Administators or everyone), and see if that works.Finally I would use ProcMon to see if it can spot the User identity under which the access is being performed http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
CarlosAg
Marked your answer. I will have to look into your last comment later this week since time has been on short supply, but the help is much appreciated!
Anton
A: 

Might not be relevant to you - but if you are running the app pool as a domain user, the rules change on the automatic injection of IIS_IUSRS token into the process at startup. This caught us out recently when moving to .net 4, and not having permission on the new Temporary ASP.net Files directory.

See here for a workaround: http://www.yusufozturk.info/iis7/asp-net-write-access-error-on-iis7-5.html

Robbo