Kerberos双跳问题求助：新域迁移后身份模拟与委派异常

Alright, let's tackle this Kerberos double-hop problem you're facing—this is a super common pain point after environment migrations and OS/SQL upgrades, especially with your WPF → WCF → SQL architecture. Let's walk through the key checks and fixes step by step:

1. Verify SPN Configurations (Critical for Kerberos) #

Kerberos lives and dies by correct Service Principal Names (SPNs), especially with named SQL instances. Let's make sure both your WCF service and SQL Server have the right SPNs registered:

WCF Service SPNs #

Your WCF service runs under a domain account (let's call it svc_wcf), so you need to register SPNs for the web server's fully qualified domain name (FQDN) and netbios name:

setspn -S HTTP/your-web-server.corp.com corp\svc_wcf
setspn -S HTTP/your-web-server corp\svc_wcf

Run setspn -L corp\svc_wcf afterward to confirm these SPNs show up—no duplicates, no missing entries.

SQL Server Named Instance SPNs #

For your named SQL 2017 instance, you need SPNs tied to the SQL service account (e.g., svc_sql). Since named instances often use dynamic ports, first fix the instance to use a static port (in SQL Server Configuration Manager), then register:

setspn -S MSSQLSvc/your-sql-server.corp.com:YourInstanceName corp\svc_sql
setspn -S MSSQLSvc/your-sql-server.corp.com:StaticPortNumber corp\svc_sql

Again, use setspn -L corp\svc_sql to verify these are correctly registered.

2. Configure Constrained Delegation for the WCF Service Account #

The double-hop problem happens because Kerberos won't pass credentials by default beyond the first server. To fix this, you need to delegate the WCF service account's permissions to authenticate against SQL Server—always use constrained delegation (non-constrained is a security risk):

• Open Active Directory Users and Computers, find your svc_wcf account, right-click → Properties → Delegation tab
• Select "Trust this user for delegation to specified services only"
• Click "Add" → "Users or Computers" → find your SQL service account (svc_sql) and select it
• In the list of services that pops up, check all the MSSQLSvc entries you registered earlier
• Make sure "Use any authentication protocol" is selected (or Kerberos if your environment enforces it)

3. Lock Down IIS & WCF Authentication Settings #

You already disabled Anonymous and Forms Auth, but let's tweak a few more things to force Kerberos:

IIS Settings #

• On your IIS site, go to Windows Authentication → Providers → move Kerberos to the top of the list (NTLM should be below it)
• Ensure ASP.NET Impersonation is enabled and set to "Authenticated user"

WCF Config #

Update your WCF service's web.config to explicitly use Windows authentication and Kerberos, plus enable impersonation if needed:

<bindings>
  <basicHttpBinding>
    <binding name="KerberosEnabledBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <serviceAuthorization impersonateCallerForAllOperations="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

4. Validate SQL Server Permissions & Auth Mode #

• Confirm SQL Server is set to Windows Authentication Mode (in SSMS, right-click server → Properties → Security)
• Make sure the end user's domain account (used by the WPF app) has login access to SQL Server and appropriate permissions on the target database (either directly or via a domain group)
• Double-check that your SQL service account (svc_sql) has permissions to read AD SPN data—domain accounts usually have this by default, but it's worth confirming if you've locked down AD permissions.

5. Test Kerberos Authentication #

Once you've made these changes, verify that Kerberos is actually being used:

• On the web server, run klist sessions in Command Prompt—you should see a Kerberos ticket for the SQL Server SPN from the client's domain account
• On SQL Server, run this query to check the auth scheme for your connection:

  SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID
  

  If it returns KERBEROS, you're good to go. If it's NTLM, you still have an SPN or delegation issue—clear cached tickets (restart IIS/SQL, or have clients log out/in) and recheck your settings.

Pro tip: If you're still stuck, use the Kerberos Configuration Manager tool (from Microsoft) to scan for SPN errors and delegation issues—it's a huge time-saver.

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