能否绕过Application Pool Identity，改用用户域账户通过SSPI认证连接SQL Server？

Absolutely—you can configure your web app to use the end user's domain account (instead of the Application Pool Identity) for SSPI-based SQL Server connections. The approach depends on whether your web app and SQL Server are hosted on the same server or separate ones, but both methods let you avoid relying solely on the app pool identity.

How to Implement This #

1. Impersonation (Same Server / Single-Hop Scenario) #

If your web app and SQL Server are on the same machine, enabling impersonation is the simplest solution:

• Update your web.config to turn on impersonation:

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

• In IIS, enable Windows Authentication for your app and disable Anonymous Authentication. This ensures users log in with their domain credentials.
• With impersonation active, the app temporarily runs under the authenticated user's context. When you use Integrated Security=SSPI in your SQL connection string, it will use the user's domain account instead of the app pool identity.

2. Kerberos Constrained Delegation (Cross-Server / Double-Hop Scenario) #

If your web app and SQL Server are on separate servers, basic impersonation won’t work (it can’t pass credentials across servers—this is the "double-hop" problem). You’ll need to set up Kerberos delegation:

• First, confirm Windows Authentication is enabled for your web app, and that IIS is using Kerberos (not NTLM). You can verify this with tools like klist or checking authentication logs.
• Register a Service Principal Name (SPN) for your web app’s application pool account in Active Directory. For example:

  setspn -S HTTP/your-web-server.your-domain.com DOMAIN\your-app-pool-account
  

• In Active Directory, edit your app pool account’s properties and enable Trusted for Delegation—specifically constrained delegation to the SQL Server service’s SPN (e.g., MSSQLSvc/your-sql-server.your-domain.com).
• Keep using Integrated Security=SSPI in your connection string; Kerberos will securely pass the end user’s domain credentials from the web server to SQL Server.

Key Considerations #

• User Permissions: The end user’s domain account must have the necessary database permissions (like db_datareader, db_datawriter, or custom roles) on the SQL Server.
• Security Risks: Impersonation and delegation can expand access scope if misconfigured. Only grant delegation rights to required accounts, and avoid over-permissioning users.
• Kerberos Troubleshooting: Missing or duplicate SPNs are a common cause of failures. Use setspn -L to verify existing SPNs for your accounts.

内容的提问来源于stack exchange，提问作者Roger Seto