When Kerberos is set up in the Kantega Single sign-on add-on, it will, upon the first visit from a browser, send a request to the browser if a Kerberos ticket is available. Then, if the browser is Kerberos enabled and runs in a Kerberos enabled environment (this is often, but not always a Windows environment), the browser will request the operating system for a Kerberos ticket for the given web site. The web site is during this request identified against Active Directory or other KDC (Key Distribution Center) using the site's canonical name (the DNS A record). The KDC names this identity as service principal name.
...
However, issues.example.com can also be a CNAME alias to a different host, say server123.example.com. In that case, server123.example.com is the canonical name of the site.
Use the command nslookup in a terminal/command prompt window to find details on if issues.example.com is an A record or CNAME. In the below example of nslookup issues.example.com is an A record (canonical name), while documentation.example.com is a CNAME alias pointing to the A record wiki.example.com.
So if you want to create a keytab for the site https://documentation.example.com you would use wiki.example.com as Canonical name.
...
Forming the Service Principal Name of the site.
...
If the Kerberos ticket is valid, the user name is extracted, an account is looked up in the product using any configured User Directories, and the user is logged in.
Advanced note: The user name inside the Kerberos ticket is usually on the format sAMAccountName@domain, so for a user, Mark Miller, this could be, for instance, marmil@example.local.
If your users are in Microsoft Active Directory, and you have set up this user directory using userPrincipalName as the User Name Attribute (e.g., mark.miller@example.com), then we will look up the user's userPrincipalName from AD using the sAMAccountName from the Kerberos ticket. This will also make Kerberos login work when the User Name Attribute is userPrincipalName.