This afternoon has been one of those annoying situations where you burn lots of time trying to resolve a problem, only to find that:
- the solution is easy-peasy
- you wonder why you didn't try the resolution sooner
- you discover some new 'quirk' about the system you're using.... which kind of answers the above question!
I've spent most of this afternoon troubleshooting a security issue with a web-based BizTalk administration tool that I was trying to deploy to a new server. Part of the tool performs some remote performance monitoring of BizTalk application servers, which obviously requires a specific security rights.
The site runs within its own application pool (on Windows Server 2003), which was using a domain user account as its identity - needed due to the remote monitoring requirement. I was pretty certain that I'd got the security requirements nailed, but despite this I could not get the site to work using the domain account, yet it worked fine using a local account with exactly the same local group membership.
Anyway after spending way too much time double-checking all sort of other settings, and confirming that the IIS worker process and the ASP.NET request were definitely running in the intended user context, I realised that in-between the various group membership changes I had made at the start of this saga, I had only been stopping and starting the application pool.
This, despite actually stopping the physical process running the application pool (and obviously causing the ASP.NET application to restart) did not allow the newly-created worker process to get its new group memebership details. Performing a full IISRESET, on the other hand, had the desired effect and the everything started working as expected.
Seems like there must be some kind of caching going on somewhere...... maybe the IIS Admin/WWW service caches group memebership information at startup, and worker processes use this? Whatever the reason, it seems that when an IIS 6 worker process gets created it doesn't logon in the same way as a usual system service.
I imagine this can be explained by the IIS 6 architecture somehow, however, for now I just need to make up some time!