Are EasySSO Server Licenses Still Available to Purchase?
Once you have your NTLM authentication working enabling Kerberos support on the EasySSO side is as easy as checking a checkbox in the config screen. Please make sure you have NTLM SSO working first.
Your AD/domain administrators will have to create a Service Principal Name for the service thus mapping the hostname of your application to the computer account used by EasySSO:
setspn -s http/<server name of you Atlassian application as you will use in the Browser> <easysso-computer-account>
Example:
setspn -s http/jira.mydomain.org jiraSSO
You will need to run "setspn" for the host name you use or plan to use when accessing the service. For example, if you plan to access Confluence via long and short URL for example - you'll need to run setspn for both.
This command effectively tells the browser "when you are accessing this URL you can respond to Negotiate authorization challenge with Kerberos ticket targeted at this principal/computer". As such you need to enumerate all URLs that can potentially be used.
Please understand, if the browser cannot negotiate Kerberos in principle (an SPN is missing, or there is no direct connectivity to the Domain Controller e.g. over VPN, or when the user is logged in to their workstation with a local profile) it will automatically fallback to NTLMv2.
If you are running a Data Center edition of the base Atlassian application, with multiple nodes, you will require multiple computer accounts (one per node) to have NTLMv2 work in this case, via computer account specific to the node (they get automatically distributed/assigned on startup).
For Kerberos, the SPN has t
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 of the login page or log out after a 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 the items below, and examine logs, specifically jespa.log - here is how to get the logs. Chat with 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
- NTLM works but with Kerberos I am getting "Mechanism level: Checksum failed" errors in the log?
- Determining if client is doing NTLM or Kerberos
If command #1 has returned a result that indicates 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 its 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.
Please review the following page in the documentation for PingFederate in regard 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 may 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.
Browsers, especially those other than Internet Explorer may require some massaging before Kerberos and NTLM will be successfully negotiated. Please review the instructions for PingFederate while we are working on adding a similar section to our site - the actions to make EasySSO work will be equivalent.