...
If the Keytab file is outdated, the Kerberos ticket will not match its signature, and the login will be aborted. The character of the Kerberos ticket is that its size in kilobytes will increase when the user has been given many roles/access groups in the KDC. Its size may get up to 20-30 kilobytes or more. Since the way the Kerberos ticket is transferred is in the HTTP headers of the web page request, the maximum header size of the involved web servers running the website must often be increased. This involves increasing the header size of the Atlassian product's built-in Tomcat web server and also eventual reverse proxies used, for instance, to terminate SSL. The Web Server Test under the Kerberos tab in the Kantega SSO Enterprise app will analyze if the header size is set up correctly and give advice, if necessary, on how to increase this for some common web servers.
...
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
...
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.info
Advanced note: The 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. |