Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Windows user


JIRA running at

JIRA's Service Principal Name


JIRA's service account

svc-jira-sso@HQ.COM COM 

Domain trust


Or , using words:

Windows user janedoe@EXAMPLE.LOCAL wants to sign in to a JIRA instance running at URL

The service principal name HTTP/ is mapped to the service account svc-jira-sso@HQ.COM. EXAMPLE.LOCAL and HQ.COM are domains in the same forest, having a domain trust relationship with each other.


  • Jane's browser first connects to a domain controller, for EXAMPLE.LOCAL, requesting a Kerberos service ticket for the SPN HTTP/

  • Since this SPN does not exist in EXAMPLE.LOCAL domain, the domain controller searches the Global Catalog instead and finds the service account svc-jira-sso@HQ.COM

  • The EXAMPLE.LOCAL domain controller responds back to the browser with a Ticket Granting Ticket for janedoe@EXAMPLE.LOCAL in the HQ.COM domain

  • Jane's browser now connects to an HQ.COM domain controller, again requesting a Kerberos service ticket for the SPN HTTP/

  • The HQ.COM domain controller issues a service ticket for service HTTP/ and user janedoe@EXAMPLE.LOCAL

  • Kantega SSO validates that the ticket is valid and authenticates janedoe@EXAMPLE.LOCAL

For this to work, all users in EXAMPLE.LOCAL must have network access to request tickets from HQ.COM domain controllers. If a firewall prevents this, Kerberos authentication will fail. 

What when there is no trust?

If domains A and B are totally independent (no trust relationship exists, different companies, etc.), then you need to issue keytab files in each domain and then upload each file to Kantega SSO.