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):
MSSQLSVC/tor-sql-01.domain.local:1433
If you use a user object to auth (such as a service account, or admin account):
MSSQLSVC/username:1433
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/server1.company.local:1433 is registered on these accounts:
CN=SERVER1,OU=servers,OU=resources,DC=company,DC=local
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/server1.company.local:1433) 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.
Sources:
http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAServicePrincipalNameSPN.html
http://msmvps.com/blogs/vandooren/archive/2008/03/11/getting-rid-of-the-duplicate-spn-in-active-directory.aspx
http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToUseServicePrincipalNames.html
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):
MSSQLSVC/tor-sql-01.domain.local:1433
If you use a user object to auth (such as a service account, or admin account):
MSSQLSVC/username:1433
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/server1.company.local:1433 is registered on these accounts:
CN=SERVER1,OU=servers,OU=resources,DC=company,DC=local
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/server1.company.local:1433) 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.
Sources:
http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAServicePrincipalNameSPN.html
http://msmvps.com/blogs/vandooren/archive/2008/03/11/getting-rid-of-the-duplicate-spn-in-active-directory.aspx
http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToUseServicePrincipalNames.html
Comments
Post a Comment