As previously stated, a SPN is a kind of alias for a domain account. You can have many SPN for a single domain account, but the SPN must be unique in the forest.

The name consists of two mandatory parts (service class and host) and two optional parts (port and service name).

The full syntax is:

service class/host[:port[/service name]]

Today I will  be talking about service class and host.

Host name is reasonable obviously: it is the host name that the client is using when accessing the service.

In the simples form, host name is the name of the server, e.g.

  • MYSERVER
  • MYSERVER.MYDOMAIN.COM

While servername appears to be an attractive choice, it has a major disadvantage when it comes to the scalability (or high-availability) of your application: you can only host the application on a single server.

Scaling the application to multiple servers can be achieved in many ways, e.g. using DNS Round robin, a hardware load balancer or using Network Load Balancing (NLB). In all cases the client is resolving a hostname to an IP-address and is then initiating a conversation with that IP address. The client does not know what server it is connected to - it could be a server with more than one IP-address or it could be a random server in a huge web farm with many hundreds servers. In all case you need a virtual hostname that is shared between all the servers.

The name resolution from the virtual hostname to IP-address is managed by the DNS server where you can make either an A-record (one or more fixed IP-addresses) or a CNAME (an alias for a hostname). If possible you should always use an A-record, as some applications (e.g. older Internet Explorer versions) does not like the combination of Kerberos and CNAME.

To prepare for scalability in the future where the demand of the HRWEB application exceeds one server you must therefore register (in DNS) an A-record for the HRWEB application

  • HRWEB.MYDOMAIN.COM

and tell the users to access the application using the url http://hrweb.

It is recommended to register the SPN for both the NetBIOS name of the server (HRWEB) and the  Fully Qualified Domain Name (FQDN) of the server (HRWEB.MYDOMAIN.COM) to ensure that the client can get a ticket no matter what syntax the client is using.

Service class is trickier to understand.

If you search for SPN registration you may find many examples where the service class is HTTP, but in reality the service class is just a random name that you chose when you are designing your client/server application. 

If your client is a web browser, then the developer of the web browser made that choice for you, and yes - in that case the service class it is always HTTP.

Other well-known samples is MSSQLSvc that is used by SQL Server and HOST that is a common service class used by many Windows services like File and Print.

For solutions where you are writing both the client and server applications (e.g. using WCF) you will have more freedom to choose the Service class name. The only limitation is that you must ensure that the combination of service class and hostname is unique in the Active Directory forest.

I will come back to service class in a future post about constrained delegation.