Revisited: Insufficient Permissions on web.config when delegating administration of a web site to remote users in IIS 7

I have been meaning to return to this since I first posted on it and gave my talk about the remote management of IIS 7 at NxtGenUG Southampton. Well I've finally gotten around to it.

This error occurred when remote administration of an IIS 7 web site and/or application is delegated to an IIS 7 user, and that user attempts to alter a setting of the site/application from a remote machine. The solution that I originally posted was to grant the local Service account modify permissions on the web.config file in question. This always seemed unsatisfactory to me as it quite a sweeping grant that increases the surface area for security issues, breaking with the principal of least privilege as it does. However at the time I first looked into this it was already gone midnight and I had a big day the next day with work, a long drive, and then the talk to give, so I went to bed and decided to look into this again another day.

If you just want the solution then skip now to the bottom paragraph, if like me you believe that the journey is worth more than the destination (and if you've been struggling with this under pressure then I doubt you will) then here is also how I got there.

I finally got around to looking into this further last night (another post-midnight session). I ran procmon.exe (part of the Sysinternals suite) and replicated the issue on a new VM so that I could see what was going on 'under the hood'.

As the image above shows the wmsvc process was impersonating the NT AUTHORITY\LOCAL SERVICE account when it was denied access the web.config file of the site. So it would seem that in giving this account permissions on the web.config file I did the correct thing (I didn't so keep reading).

Something about all of this still puzzled me however, when I look at those events logged in procmon that show the wmsvc process accessing (successfully) the applicationHost.exe process it too is impersonating the NT AUTHORITY\LOCAL SERVICE account. Well you might think that makes sense, wmsvc is after all a service and that is the account that it is impersonating. The strange thing for me was this.

Looking at this what stands out to me are these two things. 1, there is no entry for NT AUTHORITY/LOCAL SERVICE. 2, there is an entry for something called WMSvc.

After a bit of Googling and reading around I have sussed what is going on, and why I couldn't work it out that evening.

With Windows Vista (and so of course Windows Server 2008) Microsoft looked to address the security risks that having services all running as the LOCAL SERVICE account poses. When I set the permissions on the web.config file to allow LOCAL SERVICE I am not just permitting the service that I am interested in (wmsvc) I am permitting any service that impersonates this user. This is after all what bothered me in the first place. Microsoft have introduced a feature termed Service Hardening that addresses this issue. What this means is that I can now give permissions that target a specific service only. Wow, that's a great (and necessary) improvement.

So the solution to the problem is this: give modify permissions to NT SERVICE\WMSvc. Do this and the remote delegated access will work like a dream, and the principal of least privelege will have been adhered to!

My only criticism of the new features in all of this is: why can't IIS Management do this setting of permission for me when I choose to delegate permissions to an IIS User for the management of a site or application? It would be a lot easier!