Multiple HTTP Service Principal Names
Luke Hebert
- 2 minutes read - 235 wordsWhen a Kerberos client authenticates to an HTTP service, it looks up the service principal name (SPN) registered in Active Directory. If that SPN is missing, duplicated, or registered under the wrong casing, authentication fails and you get a KRB5 error. The two commands below let you confirm exactly what AD has on file before you start troubleshooting the client side.
If you are using Centrify, the HTTP service principal name must be registered in uppercase (for example, HTTP/host.fqdn). A lowercase entry will not match Centrify’s lookup and will cause authentication to fail.
Verifying the SPN with ldapsearch
Use ldapsearch to query the directory directly. The filter servicePrincipalName=http/<host fqdn> returns the object that owns that SPN.
ldapsearch -LLL -x -H ldap://<kdc>:389 -D someuser@domain.com -W -b dc=belldev,dc=dev,dc=bce,dc=ca "servicePrincipalName=http/<host fqdn>" servicePrincipalNameA concrete example against a Windows 2008 domain controller:
ldapsearch -x -H ldap://w2k8-1.ad.sec.example.com:389 -D lhebert@ad.sec.example.com -W -b cn=Users,dc=AD,dc=SEC,dc=EXAMPLE,dc=com sAMAccountName=lhebertQuerying with setspn
On a Windows machine that has the AD tools installed, setspn -q performs the same lookup without requiring a bind DN:
setspn -q http/<host fqdn>If the command returns no results, the SPN has not been registered. If it returns multiple entries, you have a duplicate SPN problem and Kerberos will pick one at random, which is the most common cause of intermittent authentication failures.