In IIS security configurations, there's a crucial but often misunderstood relationship between App Pool Identity and Anonymous Authentication. While many assume Anonymous Authentication completely bypasses the App Pool Identity's permissions, the reality is more nuanced.

// Typical web.config anonymous auth configuration
<system.webServer>
  <security>
    <authentication>
      <anonymousAuthentication enabled="true" userName="IUSR" />
    </authentication>
  </security>
</system.webServer>

Even with IUSR having full permissions, the App Pool Identity (XXX account in your case) must have at least read access to:

• The physical file path
• System temporary folders (for compilation)
• Global assembly cache (if using .NET)

IIS performs two distinct permission validations:

1. Initial Access Check: Validates whether the App Pool Identity can access the resource
2. Execution Context: Then switches to the anonymous user (IUSR) for actual file operations

Here's how to properly configure permissions for both identities:

# Grant App Pool Identity read access
$acl = Get-Acl "C:\YourWebFolder"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "IIS AppPool\YourAppPoolName",
    "ReadAndExecute",
    "ContainerInherit,ObjectInherit",
    "None",
    "Allow"
)
$acl.SetAccessRule($accessRule)
Set-Acl "C:\YourWebFolder" $acl

# Confirm IUSR permissions (should be present by default)
Get-Acl "C:\YourWebFolder" | Select-Object -ExpandProperty Access | 
    Where-Object {$_.IdentityReference -like "*IUSR*"}

When using ASP.NET, additional considerations apply:

<system.web>
  <identity impersonate="true"/> <!-- Changes behavior -->
</system.web>

With impersonation enabled, the App Pool Identity check is bypassed completely, working purely with the anonymous user credentials.

For most secure configurations:

• Keep App Pool Identity as ApplicationPoolIdentity (virtual account)
• Grant read/execute to both IIS_IUSRS group (contains App Pool Identity) and IUSR
• Avoid granting modify permissions to either account

For static content scenarios, consider this alternative approach:

<location path="StaticContent">
  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="true" userName="IUSR" />
      </authentication>
    </security>
  </system.webServer>
</location>

When dealing with IIS security, there's often confusion between client authentication and worker process identity. While Anonymous Authentication (using IUSR) handles client identity, the App Pool Identity (XXX account in your case) governs the worker process context under which all code executes.

The critical misunderstanding stems from how IIS actually processes requests:

// Simplified request flow
1. Client request → IIS
2. Anonymous Auth → IUSR identity for ACL check
3. Worker process (App Pool Identity) → Actually executes the code
4. File access → Both IUSR (initial check) AND App Pool Identity (execution) need permissions

Even with Anonymous Authentication, the App Pool Identity needs:

• Read access to static content
• Execute permissions for scripts
• Modify rights for upload folders

For optimal security while maintaining functionality:

icacls "C:\YourWebFolder" /grant "IUSR:(RX)" /grant "YourAppPoolIdentity:(RX)"

If you truly want to restrict execution context to IUSR, you'd need to enable impersonation:

<configuration>
  <system.web>
    <identity impersonate="true"/>
  </system.web>
</configuration>

However, this has significant performance implications and increases attack surface.

When facing access denied errors:

1. Verify both IUSR and App Pool Identity have permissions
2. Check for inherited permission blocking
3. Review failed request tracing logs
4. Test with Process Monitor tool from Sysinternals