Understanding IIS 7 Physical Path Credentials: Logon Types Explained for Secure Web Application Configuration


2 views

When configuring web applications in IIS 7, the Physical Path Credentials setting under Advanced Settings serves a critical security function. This setting determines which account IIS uses to access the physical files on disk when serving content.

In your specific case where both Application Pool identity and Anonymous Authentication are already configured, Physical Path Credentials act as an additional layer of file system access control.

Consider these scenarios where explicit Physical Path Credentials become necessary:

// Scenario 1: Different security requirements
// Application pool runs as NetworkService
// But website content resides on a network share requiring domain credentials

// Scenario 2: Granular permission control
// You want to limit file system access beyond Application Pool identity

The two available logon types serve distinct purposes:

Anonymous: Uses IUSR account (or custom anonymous user) for file access. Best for public content with minimal permissions.

Path Credentials: Uses explicitly specified credentials. Required when:

  • Content is on remote UNC paths
  • Special permissions are needed beyond App Pool identity
  • You need to audit specific file access

Here's how to configure this programmatically using AppCmd:

// Set physical path credentials for a virtual directory
%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" 
- -physicalPathCredentials:"DOMAIN\username"
-password:"P@ssw0rd"
-logonType:ClearText

Important security considerations:

// Always prefer:
- Integrated Windows Authentication over clear text
- Application Pool isolation over global credentials
- Minimal necessary permissions

If you encounter access denied errors after configuration:

  1. Verify credentials have proper NTFS permissions
  2. Check for password expiration (especially with domain accounts)
  3. Ensure Kerberos delegation is configured for remote resources

Instead of using administrator accounts as in your current setup, consider:

1. Create dedicated service accounts
2. Apply principle of least privilege
3. Use Managed Service Accounts where possible
4. Regularly audit credential usage

When configuring IIS 7 for internal applications, the Physical Path Credentials setting often becomes a point of confusion. While your application pool runs under a specific admin account and Anonymous Authentication is configured with another admin account, these credentials handle different aspects of security.

Here's how these components interact:

Application Pool Identity → Controls worker process execution
Anonymous Authentication → Handles HTTP request authentication
Physical Path Credentials → Manages filesystem access

You'd set Physical Path Credentials when:

  • The application needs to access network shares
  • Your content directory requires different permissions than the app pool identity
  • You want to audit filesystem access separately from application execution
Logon Type Use Case Security Impact
Anonymous Basic IIS content serving Uses IUSR by default
Path Credentials Secure network resources Explicit credentials required

Here's how to set Path Credentials programmatically:

using (ServerManager serverManager = new ServerManager())
{
    Site site = serverManager.Sites["Default Web Site"];
    site.Applications["/"].VirtualDirectories["/"].UserName = "domain\\user";
    site.Applications["/"].VirtualDirectories["/"].Password = "password";
    site.Applications["/"].VirtualDirectories["/"].LogonMethod = LogonMethod.ClearText;
    serverManager.CommitChanges();
}
  • Never use domain admin accounts for Physical Path Credentials
  • Configure minimal necessary permissions (Read + Execute typically)
  • Consider using Managed Service Accounts for automatic password management
  • Audit these credentials regularly as part of security reviews

If you encounter access issues:

  1. Verify Effective Permissions on the content folder
  2. Check Event Viewer for detailed access errors
  3. Test credentials manually using runas /netonly
  4. Review IIS authentication precedence rules