Creating the Kerberos Service Principal Name (SPN) identity

The SPNs used by Content Platform Engine should always be in one of the following forms:

FNCEWS/host_name
FNCEWS/host_name@DOMAIN.COM
FNCEWS/host_name.DOMAIN.COM

The leading FNCEWS is the Content Platform Engine service name and is needed on all its SPNs. The other parts of the SPN show where the Content Platform Engine server resides, as a simple DNS name or a simple DNS name qualified with a domain. The host_name and DOMAIN.COM must be changed according to the real name of the Content Platform Engine server and its real domain name.

As an example, the Content Platform Engine server undistinguished DNS name (the host name) might be MYCE01 and its domain might be MYDOM.EXAMPLE.COM. In this case the SPNs would be:

FNCEWS/myce01
FNCEWS/myce01@MYDOM.EXAMPLE.COM
FNCEWS/myce01.mydom.example.com

The host name should always be lower case and the domain name always upper case for the FNCEWS/host_name@DOMAIN.COM form and all lowercase for the FNCEWS/host_name.domain.com form. Windows systems are mostly case-insensitive but not everything is, so always use the proper case.

The SPN identity is a Windows domain user account that has been mapped to the SPN. This special user account has a password and from that the Key Distribution Center (KDC) derives a key, which will be used to encrypt parts of the Kerberos ticket. This key is a shared secret that is known only to the KDC, which issues Kerberos tickets, and to the service itself (Content Platform Engine in this case).

How does the client know what the SPN is? In some cases it derives this from the URL it uses to connect to the Content Platform Engine server. If that URL is, for instance, http://mysvr:9080/wsi/FNCEWS40SOAP, it uses an SPN of FNCEWS/mysvr. If the URL is http://mysrv.mydom.example.com:9080/wsi/FNCEWS40SOAP, it uses FNCEWS/mysvr@MYDOM.EXAMPLE.COM. Other clients use a simple algorithm like this or directly specify the SPN.

How does the KDC know about the SPN and how does it know what key to use with that? The answer, with a Windows KDC, is that there must be one domain user account set up (with some password, of course), this identity user account must be specifically mapped to one or more SPNs, and that account provides the key. The KDC is referred to on Windows systems as a Domain Controller.

How does the Content Platform Engine server know what its SPN is? It actually does not need to know this, but it can figure out the name of the identity user account by using FNCEWS_ + host_name (for example, FNCEWS_myce01 for our example Content Platform Engine server named MYCE01). If some other identity user account name must be used for some reason, as it would if this server was a member of a cluster or if the system name is long, the name can be directly specified by the serviceAccountName option (see KrbServiceLoginModule Options and Using Kerberos with a cluster of Content Platform Engine servers).

How does the Content Platform Engine server know what key to use for decrypting its part of a Kerberos ticket? It does this by logging on to the identity user account by using the password stored in a keytab, a special Kerberos table of users and their passwords. This special login gets the Kerberos Ticket Granting Ticket (TGT), which in turn gives the server access to its key.

The following steps of making an SPN Identity are not trivial, partly because Windows allows Kerberos interoperability with Java and non-Windows operating systems, but has never tried to make it user friendly.