qUICKLY Explained: Service Principal Name: Registration, Duplication

  • [アーティクル]

Hello, its "q" again and ready to write something quickly regarding Service Principal Names (SPN).

Service Principal Names are registered by services in order for clients to identify them in a domain. Before a client can connect to a service, it must compose the SPN for that instance of service, connect to the service, and finally present the SPN for authentication via Kerberos. The client specifies the components of the SPN using known data or data retrieved from sources other than the service itself.

 Each instance of a service registers its own unique SPN. There can be multiple unique SPNs for a given service used for authentication by the clients. The format of the SPN is that it includes the hostname of the computer where the service is running, the service class, and the port number:

               < service class>/<host>:<port>/<service name>

e.g.          MSSQLSvc/MySQLServer1.MyDomain.com:1433

The SPN syntax has four elements: two required elements and two additional elements. In this form, "<service class>" and "<host>" are required. "<port>" and "<service name>" are optional

e.g.        MyService/host1.contoso.com/CN=Server1,OU=Servers,DC=Contoso,DC=com

     MyService/host2.contoso.com/CN=Server2,OU=Servers,DC=Contoso,DC=com

 Or using NetBIOS

MyService/host1/CN=Server1,OU=Servers,DC=Contoso,DC=com

MyService/host2/CN=Server2,OU=Servers,DC=Contoso,DC=com

For more information about SPN format, see Name Formats for Unique SPNs.

So how do these SPNs get registered? and how can I easily find them for a particular object in AD? SPNs must be registered on an object the service instance uses to run. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services called servicePrincipalName. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information on this, see How a Service Registers its SPNs.

An SPN must be unique in the forest in which it is registered. If it is not unique, authentication can and will fail for clients accessing this service as there are more than one instances registered with the same SPN. It is similar to having two hosts registered with the same IP, though this causes conflict on the network, duplicate SPNs will cause Kerberos/authentication issues.

Below table summarizes each element of the SPN.

Element

Description

"<service class>"

A string that identifies the general class of service; for example, "SqlServer". There are well-known service class names, such as "www" for a Web service or "ldap" for a directory service. In general, this can be any string that is unique to the service class. Be aware that the SPN syntax uses a forward slash (/) to separate elements, so this character cannot appear in a service class name.

"<host>"

The name of the computer on which the service is running. This can be a fully-qualified DNS name or a NetBIOS name. Be aware that NetBIOS names are not guaranteed to be unique in a forest, so an SPN that contains a NetBIOS name may not be unique.

"<port>"

An optional port number to differentiate between multiple instances of the same service class on a single host computer. Omit this component if the service uses the default port for its service class.

"<service name>"

An optional name used in the SPNs of a replicable service to identify the data or services provided by the service or the domain served by the service. This component can have one of the following formats:

  • The distinguished name or objectGUID of an object in Active Directory Domain Services, such as a service connection point (SCP).
  • The DNS name of the domain for a service that provides a specified service for a domain as a whole.
  • The DNS name of an SRV or MX record.

Be aware that if the DNS name of a computer changes, the system updates the "<host>" element for all registered SPNs for that host in the forest.

For duplicate SPN events, look for  Event ID 11 in the System Logs- Duplicate SPN, on domain controllers that say:

Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 11
Date: 4/1/2002
Time: 1:40:14 PM
User: N/A
Computer: ComputerName
Description: There are multiple accounts with name host/mycomputer.mydomain.com of type 10.

For this, steps mentioned in the KB https://support.microsoft.com/kb/321044 can be used to remove any duplicates; I prefer the LDP method or even using ADSIEDIT.MSC assuming you know where the duplicate SPN is, so you can remove it from the ServicePrincipalName attribute of the account registering this SPN. But now that most of us should be running Windows Server 2008 or R2, there is an easier way to find these duplicate SPNs using SETSPN in 2008 / R2.

While SETSPN was part of Resource Kit in Windows 2000 / 2003, it is now part of the Windows Server 2008 / R2 OS and the new switches are:

Modifiers:
-F = perform the duplicate checking on forestwide level
-P = do not show progress (useful for redirecting output to file)

Switches:
-R = reset HOST ServicePrincipalName
Usage:   setspn -R computername
-A = add arbitrary SPN
Usage:   setspn -A SPN computername
-S = add arbitrary SPN after verifying no duplicates exist
Usage:   setspn -S SPN computername
-D = delete arbitrary SPN
Usage:   setspn -D SPN computername
-L = list registered SPNs
Usage:   setspn [-L] computername
-Q = query for existence of SPN
Usage:   setspn -Q SPN
-X = search for duplicate SPNs
Usage:   setspn -X

-X will allow you to find duplicate SPNs making troubleshooting easier for us.

Comments

  • Anonymous
    January 01, 2003
    Thanks for sharing your most valuable knowledge.

  • Anonymous
    January 01, 2003
    Great article, Q! Thanks!

    Tricky note found in the "setspn /?":
    "SPNs are not required to be unique across forests, but duplicates can cause authentication issues when authenticating cross-forest"

  • Anonymous
    October 12, 2010
    Really enjoying your blog so far Q...thanks for being part of the AD community. Thanks Mike

  • Anonymous
    October 30, 2010
    Learning a lot from your quickly explained logs, they are to the point, thanq

  • Anonymous
    April 10, 2013
    I am not clear as to why are we associating the SPN to only one user?

  • Anonymous
    June 11, 2013
    Great article! Got another one, not as detailed as this one but with more information about delegation (the next step) geertbaeten.wordpress.com/.../kerberos-authentication-and-delegation-serviceprincipalnames

  • Anonymous
    June 16, 2014
    That was good Info

  • Anonymous
    November 25, 2014
    ThanQ Mr.Q a straight drive to the issue and solved it.