I usually hate to agree with the detractors of Microsoft and uses often, because it’s right, the argument that Microsoft products are very secure if it has been installed, configured and tuned properly. My thought is: in 90% of the cases, the root cause is located between the chair and the keyboard. On this one, unfortunatly, Microsoft missed something big…
Have a try yourself by running this powershell command on your webserver (IIS 6.0 and 7.0 – I can’t check right now on 7.5 and 8.0):
Get-WmiObject -NameSpace root/MicrosoftIISv2 -Class IIsApplicationPoolSetting -Property Name, WAMUserName, WAMUserPass | Select Name, WAMUserName, WAMUserPass
So Microsoft is right to say:
For maximum security, application pools should run under a special built-in identity called ApplicationPoolIdentity. There are two types of Identity for the application pools: Built-in and Custom. The built-in accounts are ApplicationPoolIdentity, NetworkService, LocalService, and LocalSystem. The default (recommended) and most secure is ApplicationPoolIdentity.
The good news is: that’s my new best example to explain why the ApplicationPoolIdentity must be set to a “lower priviledges has possible” account.
Another way, via appcmd:
appcmd list apppool /config
And now, of course, there’s a solution: Using Encryption to Protect Passwords