This article shows the end user experience when a user logs in from an Active Directory domain-joined device.
The examples used here assume that the user is logging in to Jira using Google Chrome on Windows computer which is joined to an Active Directory domain.
The end-user experience should be very similar for users logging in different Atlassian applications, or using another browsers or operating systems.
Username and password login
First, let's review Jira's out-of-the-box username and password login experience:
The user enters their username and password and clicks to log in. Jira then verifies the password, either by checking its local internal user directory, or more typically by delegating to an external user directory such as LDAP or Crowd.
When Kerberos login is enabled in Polar SSO, users no longer see the standard dialog for entering a username and password. Instead, Polar SSO requests an Active Directory Kerberos service ticket from the user's browser. The browser then contacts Active Directory to get a service ticket and forwards it to Jira in a new request.
For the end user, all of this happens in the background, completely transparently. The user simply navigates to Jira (or clicks on a link) and is magically logged in.
Logging into a different account
It may some times be useful to log in to a Jira account which is different than the one logged in to the device. To switch to another account, the user can log out form Jira by selecting "Log out" the normal way.
Polar SSO will detect that the user wanted to log out and prevent the next automatic Kerberos login from happening. This allows the user to log into another account as if Kerberos was not enabled in Jira.
Logging in without Kerberos
If the browser fails to acquire a service ticket for Jira, Polar SSO falls back to showing the regular login page.
This allows users to continue logging in, even when using devices which are not domain-joined or when the browser is temporarily prevented from requesting a ticket from Active Directory (VPN, firewalls etc).
For advanced use cases, an administrator can configure which browsers/ user agents and network locations should be offered to sign in with Kerberos.