In a nutshell,
we have been locking down the IIS APPPOOL account used by an Internet facing web application. The IISAPPPOOL account by default belongs to a number of mandatory groups when the security token is injected into the w3wp.exe process:
Token contents:
User:
IIS APPPOOL\XXX XXXX XXXX
Groups:
Mandatory Label\High Mandatory Level INTEGRITY
Everyone MANDATORY
BUILTIN\Users MANDATORY
NT AUTHORITY\SERVICE MANDATORY
CONSOLE LOGON MANDATORY
NT AUTHORITY\Authenticated Users MANDATORY
NT AUTHORITY\This Organization MANDATORY
IIS APPPOOL\XXX XXXX XXXX LOGONID,MANDATORY
BUILTIN\IIS_IUSRS MANDATORY
LOCAL MANDATORY
S-1-5-82-0 MANDATORY
Privileges:
SeAssignPrimaryTokenPrivilege DISABLED
SeIncreaseQuotaPrivilege DISABLED
SeAuditPrivilege DISABLED
SeChangeNotifyPrivilege ENABLED
SeImpersonatePrivilege ENABLED
SeCreateGlobalPrivilege ENABLED
SeIncreaseWorkingSetPrivilege DISABLED
What this means is that anyone who can execute code on the web server (i.e a hacker) has potentially access to the operating system files and processes via their membership in the Users and Everyone groups courtesy of the IIS APPPOOL security token.
So to prevent this we have removed the permissions on the root folders and all child files and folders of the Everyone and Users groups for everything but the web root (When you do this the OS security UI complains if you try to do this when it reaches the Windows and windows\system directories). The Administrators group is left untouched.This has now locked down our web server and the IIS APPPOOL inherited permissions to our satisfaction and all applications behave as required.
However a side effect of this security lockdown is that any local administrative accounts on the local machine (there is no Domain security)except the BUILTIN\Administrator default account now have no read write or execute permissions ("Access denied") which is not what we would expect. This is despite the administrators belonging properly to the Administrators group and the Administrator group being correctly set on files (After all The default Administrator account works as expected.).
Any suggestions on how to give back Administrative privileges to non default administrative accounts without having to reinstate the Authenticated User and Everyone group permissions or to explicitly set any non Default administrator accounts (we actually ony need one additional non default admin account)
The environment is Windows Server 2008 R2 IIS 7.5
Additional comment:
This is not specifically an IIS problem. This is a side efect of our APP POOL lockdown. This could be replicated on any default Windows installation. Remove the default Everyone and Users Groups from the root of a drive. Add or leave Administrators group with full control to the root of a drive if not already. Logon as a non default administrator (i.e not the BUILTIN\Administrator account). The so called "administrative user" can not enumerate files, launch programs on that drive (Using RunAs Administrator leads to "The Parameter is incorrect" dialog. In other respects the administrator has some administrative abilities, i.e. can interrogate Permissions/Security UI, Can logon remotely without explicit membership in Remote Users etc. Running Process monitor readily demonstrates "ACCESS DENIED". The "problem" can be solved by explicitly adding permissions for each administrative account. But that should not normally be necesary. Group membership should be sufficient.
We would appreciate anyone else reproducing this or for someone to note some configuration we may have missedor general discussion about dealing with the Everyone/Users groups, especially outside the webroot itself.