The most frequent cause of this is the mismatch in SPN that browser has obtained for the server (i.e. what it thinks it is connecting to) and the one mapped to the computer account that was created (i.e. what it is actually talking to)
To make Kerberos reliably work across all browsers it is highly recommended to have SPN for the server name that is not a CNAME/alias. To make sure run the following:
nslookup <server name of you Atlassian application as you will use in the browser> nslookup <the ip of the server (not dns server) as returned by the nslookup above> setspn -l <easysso-computer-account> setspn -Q */<server name of you Atlassian application as you will use in the browser>
If the server name is an A type record in your DNS and resolves to the IP directly (by command #1), and the IP resolves back (by reverse lookup #2), the HTTP/servername SPN exists and points to the computer account used in EasySSO (command 3) and it's the only HTTP SPN (command 4) - you should be all set. Test in Incognito/In-Private mode or with another browser. If you are kicked out to login page or logout after successful SSO, make sure you close the browser window (to clear out the cookies) and then navigate to the Atlassian application again in a new browser window. If you receive any error messages or observe some unexpected behaviour (e.g. domain credentials popup), please review items below, and examine logs, specifically jespa.log - here is how to get the logs. Chat to our 24x7 support (bottom right of this very page) and we will assist you.
Read these articles in our FAQ:
- NTLM works but with Kerberos I am getting "Encryption type AES256 is not supported" errors in the log
- Determining if client is doing NTLM or Kerberos
If command #1 has returned result that indicate the server name is a CNAME or "alias" of the actual VM/machine name, i.e. the name you are typing into your browser is a "service" hosted on that "machine", run this one too:
setspn -Q */<machine name>
Most of the time the machine will already have it's own SPNs (e.g. it is joined to the domain). If you are getting "checksum failed" errors in jespa.log - this is the most likely reason.
Don't remove the machine SPNs. Instead, in your DNS map the service name to the same IP address as an A record instead of CNAME.
If the DNS name of the service is a CNAME, presence of the SPN for this name will trigger the sending of Kerberos ticket in response to Negotiate challenge, but the target SPN included in the ticket may not match the server name as browser may canonicalize the hostname.
Please review the following page in the documentation for PingFederate in regards to hostname canonicalization, or reverse DNS lookups. If your setup is more complex than a standalone host with DNS containing A and PTR record - you will need to create additional Service Principal Name mappings.
Do take the possibility of different results for DNS resolution in different scenarios into account - intranet, extranet, VPN, etc. Having the same exact hostname resolve to a different IP address when on the internal network (to the host itself) than the one when on the external network (to the SSL appliance or firewall) is a very common scenario. This may require adding additional SPNs for the hostnames identified via reverse DNS lookup.
The same error is returned when the SPN that browser is using is mapped to a different account. As such please verify the output of "setspn -s" carefully when adding SPNs for the computer account used by EasySSO.