When configuring IIS 7 with domain user accounts as application pool identities, the permission requirements differ based on your application type. The application pool identity serves as the security context under which your web applications run, making proper permissions crucial for both security and functionality.
For a basic static website (HTML, CSS, JS files), the domain user needs:
• Read & Execute permissions on the site's root directory
• Read permissions on all content files
• Traverse Folder permissions on the directory structure
• IIS_IUSRS group membership (for temporary files)
For ASP.NET applications, additional requirements include:
• Modify permissions on the Temporary ASP.NET Files directory
• Read/Write permissions on any upload folders or database files
• Access to the Windows registry (for machineKey and other configurations)
• Membership in the IIS_WPG group for worker process management
Use PowerShell for efficient permission assignment:
# Grant basic permissions
$acl = Get-Acl "C:\inetpub\wwwroot\mysite"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("DOMAIN\AppPoolUser","ReadAndExecute","Allow")
$acl.SetAccessRule($rule)
Set-Acl -Path "C:\inetpub\wwwroot\mysite" -AclObject $acl
# Special case for ASP.NET temp files
$tempAcl = Get-Acl "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"
$tempRule = New-Object System.Security.AccessControl.FileSystemAccessRule("DOMAIN\AppPoolUser","Modify","Allow")
$tempAcl.SetAccessRule($tempRule)
Set-Acl -Path "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" -AclObject $tempAcl
When troubleshooting permission problems, check these key areas:
- Event Viewer logs for specific access denied errors
- Effective permissions using
icacls
command - Inheritance issues (sometimes explicit denies override inherited allows)
While configuring permissions:
- Always follow the principle of least privilege
- Use separate domain accounts for different application pools
- Regularly audit permissions using tools like AccessChk
- Consider using Managed Service Accounts where available
When configuring IIS 7 with domain accounts as application pool identities, the security model becomes more complex than using built-in accounts like Network Service. Here's what you need to know:
// Example of setting app pool identity programmatically
using (ServerManager serverManager = new ServerManager())
{
ApplicationPool pool = serverManager.ApplicationPools["MyAppPool"];
pool.ProcessModel.IdentityType = ProcessModelIdentityType.SpecificUser;
pool.ProcessModel.UserName = "DOMAIN\\apppooluser";
pool.ProcessModel.Password = "SecurePassword123!";
serverManager.CommitChanges();
}
For a basic website running under a domain account, these NTFS permissions are mandatory:
- Read & Execute on the website root directory
- Read permission on all content files
- Modify on the \temp\ directory (if applicable)
- Full Control on the application's \App_Data\ folder
When hosting ASP.NET applications, additional considerations come into play:
icacls "C:\inetpub\wwwroot\MyApp\" /grant "DOMAIN\apppooluser":(OI)(CI)(RX)
icacls "C:\inetpub\wwwroot\MyApp\App_Data\" /grant "DOMAIN\apppooluser":(OI)(CI)(M)
You'll also need these specific privileges:
- Access to the Temporary ASP.NET Files directory
- Windows Token Cache service access (if using Windows authentication)
- Registry access to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET
Instead of manual configuration, consider these approaches:
# PowerShell script to apply standard permissions
$user = "DOMAIN\apppooluser"
$path = "C:\WebSites\MyApp"
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
$user, "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl
Watch out for these common pitfalls:
- Double-hop authentication issues when accessing network resources
- File system cache permissions when using output caching
- COM component access requirements (may need DCOMCNFG adjustments)
When troubleshooting, always check the Windows Event Log and enable Failed Request Tracing in IIS:
%windir%\system32\inetsrv\appcmd set config /section:httpLogging /selectiveLogging:LogAll