How Kerberos works

When Kerberos is set up in the Kantega SSO Enterprise app, it will send a request to the browser if a Kerberos ticket is available upon the first visit from a browser. 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 website. The website 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 the service principal name.

The KDC will then, in cooperation with the operating system, generate a valid Ticket-Granting Ticket (TGT) for the website and send this back to the browser. The browser will send the ticket back to the website, and the Kantega Single sign-on add-on will pick up the ticket and verify its validity against the Keytab file. The Keytab file was earlier extracted from the KDC and installed in the Kantega Single sign-on add-on and is to be considered a certificate to approve each Kerberos ticket signed by the KDC.

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.

Before you configure your environment for Kerberos, it might also be useful to know how browser users are authenticated using 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.

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.

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

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.

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.

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.