...
Before you configure your environment for Kerberos, it might also be useful to know how browser users are authenticated using Kerberos:
...
Does the browser support Kerberos?
First, the browser decides if Kerberos should be enabled for the given site. See our browser configuration guide. If Kerberos is not enabled in the browser, you will see the regular username/password dialog instead.
...
Determining the Canonical Host Name
Your browser needs to determine the canonical DNS name of your site. If issues.example.com is an A record, then that is also the canonical name of the site. 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 the canonical name.
...
Forming the Service Principal Name of the site
The Service Principal Name (SPN) of a site is always on the form "HTTP/" + canonical hostname + "@" + REALM.
The Realm is the Active Directory domain name in dot-separated, uppercase format, e.g., EXAMPLE.LOCAL
With the canonical name issues.example.com, and a realm of EXAMPLE.LOCAL, the Service Principal Name is HTTP/issues.example.com@EXAMPLE.LOCAL
...
Acquiring a Kerberos service ticket
Your browser now sends a request to Active Directory, asking for a service ticket for HTTP/issues.example.com@EXAMPLE.LOCAL.
Active Directory performs a search in the @EXAMPLE.LOCAL domain for an account with a servicePrincipalName attribute of HTTP/issues.example.com.
If only a single account is found with this SPN, then a service ticket is issued to the client.
...
Verifying the service ticket
The browser wraps the Kerberos service ticket in a SPNEGO packet and sends it to the site as an HTTP header. Kantega SSO Enterprise decodes, parses, and verifies the service ticket against the configured keytab file. 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.
| Info |
|---|
Suppose 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). In that case, 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. |