KB001151

Host (A) Records in Service Principle Names (SPN)

The use of an A (address) RECORD and not a CNAME (Canonical Name) record is recommended when using Kerberos. This is to avoid issues where code performing Kerberos authentication resolves a CNAME to the corresponding HOST. This results in a string that is constructed for the SPN request containing the HOST record; this prevents multiple services of the same type being run on the same server.

For example, assume in DNS a CNAME of “mysite.k2.com” which is an alias for the HOST record of “server.k2.com” is used. When the user browses to a web site set with a host header of “mysite.k2.com” this will resolve to “server.k2.com” which resolves to the IP address of 192.168.1.2. “server.k2.com” is the final address in the chain which resolves to an IP address as this is the case an SPN request containing this address is used for the Kerberos ticket request. 

As the Kerberos authentication process continues, the Kerberos Key Distribution Center (KDC) hosted on domain controllers looks at the ticket request containing the SPN formed by the client the SPN string is used in a query against Active Directory by the KDC to identify the account under which the requested service (the web site) is defined to be running under. As the service account has been set with an SPN of the CNAME the service account is never found by the KDC resulting in the inability for the KDC to issue a Kerberos service ticket to the client.

To resolve this problem one might want to set the SPN on the correct service account using both the CNAME and HOST record, this however prevents multiple services of the same type executing under unique service accounts being run on the same server as each service account would require the same SPN being registered against them, this is not allowed in Kerberos and is referred to as duplicate SPNs.

A RECORD is not treated the same as resolving an IP address, this guarantees that the SPN contained in the Kerberos ticket request made by the client is always the address used by the client to access the service and also allows multiple services of the same type to be run on the same server under unique service accounts.

Apart from addressing the issue of SPN construction in ticket requests using A RECORD it also provides a high level of scalability and flexibility for Network Load balancing and in particular to support DR failover scenarios.

An example would be in the following DR design:

	Requests from Client workstations direct to K2 Server or from servers direct to K2 Server.
	DNS server holds K2 Server farm address as A RECORD with short TTL configured on record.
	Normal requests to K2 Server farm are resolved to primary site IP address.
	In event of failover requests to the K2 Server farm are returned by the DNS server resolving to the DR site.
	Primary K2 Server Farm/Node configured to run under service account on all nodes and local host entry created pointing to either Primary K2 Server address (single node) or Primary NLB VIP (multi node in each site).
	DR K2 Server Farm/Node configured to run under service account on all nodes and that of the Primary site. Local host entry created pointing to either DR K2 Server address (single node) or DR NLB VIP (multi node in each site).
	Active Directory Domain Controller, used for authentication (Please note that an instance of the KDC resides on all DCs)
	Kerberos Steps
	Client/Server requests a Kerberos ticket call to the KDC to access the K2 Servers in either Primary or DR sites, the request is always the same whichever site, SPN of “K2Server/k2server.k2.com:5252” or “K2HostServer/K2Server.k2.com:5555” is used in the request.
	An LDAP query is performed to locate a unique service account with the string “K2Server/k2server.k2.com:5252” or “K2HostServer/K2Server.k2.com:5555” set on the attribute “ServicePrincipalName”.
	The account “Svc_K2_Server” has the matching SPNs set and is the only account with these SPNs set on the “ServicePrincipalName” attribute. The accounts master key is now retrieved and used to encrypt* the session key for the requested target service.
	A session key is generated and 2 copy’s created one for the client encrypted in the clients TGT** and one for the target service encrypted in the service account master key retrieved in step 3. Both of these are passed to the client upon which the client forwards the server copy to the target service, as long as the target service is running under the account identified in step 3 the service will be able to decrypt and extract the 2nd copy of the session key.

Note: Please note all Kerberos key cryptography is symmetric

Important:  **TGT ticket granting ticket is used by the client in all Kerberos requests to encrypt the requests and replies