Fixing duplicate SPNs (service principal name)

This is a pretty handy thing to know:

SPNs are used when a specific service/daemon uses Kerberos to authenticate against AD. They map a specific service, port, and object together with this convention: class/host:port/name

If you use a computer object to auth (such as local service):

If you use a user object to auth (such as a service account, or admin account):

Why do we care about duplicate SPNs? If you have two entries trying to auth using the same Kerberos ticket (I think that's right...), they will conflict, and cause errors and service failures.

To check for duplicate SPNs:
The command "setspn.exe -X

C:\Windows\system32>setspn -X
Processing entry 7
MSSQLSvc/ is registered on these accounts:
CN=SQL Admin,OU=service accounts,OU=resources,DC=company,DC=local

found 1 groups of duplicate SPNs. (truncated/sanitized)

Note that you see the SPN (MSSQLSvc/ and two objects (CN=SERVER1 & CN=SQL Admin). Use ADSIedit.msc to view the 'serviceprincipalname' attribute for each object, and you will see the same SPN.

To figure out which one to delete, log on to the server where the service/daemon is hosted. Find out what it uses to log on to AD. In this case, it is a Microsoft SQL Server, and I can easily see what credentials it uses by checking services.msc, scrolling down to the service in question and viewing the 'log on as' column. It says 'Local Service', so therefore it uses the computer object. I can delete the SPN entry under the SQL Admin user object's SPN attribute.

Pretty simple when you get down to it.



Popular posts from this blog

DFSR - eventid 4312 - replication just won't work

Logstash to Nagios - alerting based on Windows Event ID