...
Windows user | janedoe@EXAMPLE.LOCAL |
JIRA running at | |
JIRA's Service Principal Name | HTTP/jira.company.com |
JIRA's service account | |
Domain trust | EXAMPLE.LOCAL <=> HQ.COM |
Or , using words:
Windows user janedoe@EXAMPLE.LOCAL wants to sign in to a JIRA instance running at URL https://jira.company.com.
The service principal name HTTP/jira.company.com 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/jira.company.com
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/jira.company.com
The HQ.COM domain controller issues a service ticket for service HTTP/jira.company.com@HQ.COM 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.
...