Active Directory Authentication and access
Service principal names
Find an SPN, establish which identity owns the service, and diagnose aliases and duplicate registrations.
Match the service name to the service identity
An SPN connects a service name to the AD account whose key the service can use. A typical name is HTTP/app.contoso.com; an SQL service might use MSSQLSvc/sql.contoso.com:1433. The name requested by the client is what matters. DNS successfully resolving the hostname does not establish the SPN’s owner.
Before changing AD, write down:
- The exact name used by the client, including aliases, service class, and instance or port component.
- The account actually running the accepting service.
- Any application setting that chooses machine credentials instead of the configured application identity.
- Whether the failure is on the client-to-front-end hop or a delegated back-end hop.
An SPN’s port component identifies a service instance; it does not by itself tell a firewall which transport connection the application will open.
The SPN is built by the client application or its authentication library, rather than by DNS. A short name, FQDN, alias, explicit port, and canonicalized name can produce different requests. Capture the TGS request’s service name when the application behavior is uncertain. A browser URL alone may not reveal the final requested name. Microsoft’s SPN construction guidance explains the service-class, host, and optional instance components.
Query before registering
With the AD administration tools installed, run these from an elevated prompt. Replace the sample names:
setspn -F -Q HTTP/app.contoso.com
setspn -F -Q HTTP/app
setspn -L CONTOSO\svc-web
setspn -L WEB01
-Q searches for registrations. -L lists an account’s registrations. -F widens the search to the forest; a domain-only search can miss a conflicting owner in another domain.
For a broader duplicate check:
setspn -F -X
A forest-wide search can take time in a large directory. Start with the failing SPN when you have it, and save the command’s search scope with the output. Microsoft’s setspn reference covers these switches.
When results depend on the KDC, query the exact account value on that DC as well:
Get-ADObject -Server dc1.contoso.com `
-LDAPFilter '(servicePrincipalName=HTTP/app.contoso.com)' `
-Properties sAMAccountName, servicePrincipalName, msDS-KeyVersionNumber |
Select-Object DistinguishedName, sAMAccountName,
servicePrincipalName, msDS-KeyVersionNumber
This searches the selected DC’s domain partition. For forest-wide ownership, search each relevant domain or use an appropriate GC query. Keep failed lookups too, and compare searches with the same scope; two successful results from different replica scopes can tell different stories.
Missing and misplaced SPNs fail differently
If the KDC cannot locate an SPN, it may reject the ticket request; an application using Negotiate may then fall back to NTLM, if its settings and policy permit that. If the SPN exists on the wrong account, the KDC can issue a ticket that the real service cannot decrypt. KRB_AP_ERR_MODIFIED is a common result.
Duplicating an SPN to “make both servers work” makes ownership ambiguous. Load balanced services need an identity and key arrangement supported by that application. Putting the same SPN on several independent computer accounts does not provide it.
IIS can use a different key from the worker process identity
IIS kernel-mode Windows authentication normally uses the machine credentials. An application pool running as CONTOSO\svc-web therefore does not automatically mean that HTTP.sys accepts the ticket with that account’s key. If the HTTP SPN is registered to the custom pool identity, inspect useAppPoolCredentials as well as useKernelMode and the pool identity.
On the IIS host, this reads configuration for the named site:
%windir%\system32\inetsrv\appcmd.exe list config "Contoso Web" /section:system.webServer/security/authentication/windowsAuthentication
For a supported custom-identity design, useAppPoolCredentials=true can keep kernel-mode authentication while selecting the pool account’s credentials. Work out the intended configuration first; disabling kernel mode or moving the SPN isn’t a general fix. Microsoft’s IIS Kerberos investigation covers this mismatch.
HOST mappings explain some apparent omissions
Windows has service classes that can map to an account’s HOST registration. So a missing explicit cifs/server entry in the account’s SPN list doesn’t, by itself, explain an SMB authentication failure.
Inspect the forest’s mapping attribute when this distinction matters:
$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$config" `
-Properties sPNMappings |
Select-Object -ExpandProperty sPNMappings
This is a forest configuration read. Changing the mapping affects more than the one application being investigated. The setspn documentation lists the built-in service classes recognized through a HOST SPN.
Register only after establishing the owner
Directory change: after confirming the service runs as this account, use -S for a new registration because it checks for duplicates:
setspn -S HTTP/app.contoso.com CONTOSO\svc-web
Save the existing values and the intended owner first. A misplaced registration must be removed from its old owner through a planned change; adding another registration is not a repair. Do not use setspn -R as a general service-account reset: it resets a computer account’s default host registrations.
After a change, let it reach the relevant DCs, obtain a fresh service ticket for the affected session and retry the application. setspn succeeding doesn’t tell you whether the service can use the resulting ticket.
Keytabs add a second copy of account key state
For a non-Windows acceptor, compare the SPN, realm, key version, and algorithms in its deployed keytab with the AD account and the ticket the KDC issued. A password rotation can leave the directory with new keys while the service still holds old ones. An SPN query can be completely correct in that situation.
Do not run ktpass as an inspection command: it can map principals and set an account password, depending on its arguments. Exporting another keytab without planning key ownership and deployment can break other services sharing the account. Use the service platform’s keytab-listing tool and the documented ktpass behavior to plan a controlled repair. Keep keytab contents out of diagnostic reports.
An illustrative failure: HTTP/app.contoso.com resolves uniquely to svc-web, the KDC issues a ticket, and the application still reports modification/decryption failure. The next question is which key the acceptor loaded, not whether another copy of the SPN should be added. See encryption and keys.
Cross-forest names need routing too
An SPN can be correct in the resource forest while a KDC in the account forest cannot route the client’s request there. Review the forest trust’s name suffix routing and the exact realm referrals. Keep a record of suffix and exclusion settings before rebuilding a trust; deleting the trust can discard the settings that explain the original behavior.
See trusts for the direction and routing checks, and Kerberos troubleshooting for ticket-cache inspection.