Kerberos

dns/principal name mismatch

token size

using klist

Cross realm mappings

Service Principle Names

A Service Principle Name (or SPN) is a the name in which a service is known in AD and must be unique. Some commonly seen SPN’s are like the following:
MSSQLSvc/WIN-VM-SQL02.csc.ncsu.edu:CSCMSSQL <- MSSQL Server w/ Named Instance
MSSQLSvc/HSSJJ2.oit.ncsu.edu:1433 <- MSSQL Server w/ Default Instance
CIFS/ADRIC.wolftech.ad.ncsu.edu <- CIFS SPN for Domain Controller
TERMSRV/OIT100SCCM-SS <- Kerberized RDP for SCCM Site Server
HOST/ADRIC <- Host Principle for Domain Controller using Netbios Name
MSServerClusterMgmtAPI/ENGR99WMS <- Failover Clustering Node

… and even more examples.

SPNs should exist only on Computer Objects and Service Accounts! If you have an SPN on your .admin account, you did something wrong!

Automatic SPN mappings:
Microsoft made it so that a large number of services can automatically be translated into a “HOST/*” SPN. This is for a number of services that exist as optional parts of the base server operating system. For more details.

To view the list of SPN’s that can map to “HOST/*”:
adfind -config -f spnmappings=* spnmappings

OR look at the sPNMappings Attribute on the following object (you have to use ADSI Edit to see it):
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=wolftech,DC=ad,DC=ncsu,DC=edu
Service Principle Name dynamic registration:
Many services (like MSSQL, Failover Clustering, and so on) support dynamically updating the SPN list for the object that is going to be handling the authentication. Remember how I said they need to be unique before? That’s part of the reason why when you need to cluster multiple servers into a single service, you have to use a service account (though in 2008+ many service accounts are computer accounts). To do so, the account must have the “SELF: Validated write to servicePrincipleName” permission.

Duplicate Service Principle Names:
Remember how I said UNIQUE! If there are 2 objects in AD that have the same SPN, then it is impossible for the domain controllers to figure out who is supposed to authenticate the service. This is commonly caused by people putting in their OU admin accounts for services to run as, and then later changing your mind.

Here’s one script to find duplicate SPNs: Validate SPN mappings Powershell Script

Here’s another written by folks at Stanford:

$RootNC = ([ADSI]'LDAP://RootDSE').Get('rootDomainNamingContext')
$Searcher = New-Object DirectoryServices.DirectorySearcher([ADSI]"GC://$RootNC",'(servicePrincipalName=*)',@('distinguishedName','servicePrincipalName'))
$Searcher.PageSize = 1000
$Searcher.FindAll() | ForEach-Object {
$DN = $_.Properties['distinguishedname'][0]
$_.Properties['serviceprincipalname']|
Select-Object -Property @{Name='SPN';Expression={$_}},@{Name='DN';Expression={$DN}}
} |
Group-Object SPN |
Where-Object { $_.Count -gt 1 } |
Select-Object -ExpandProperty Group