...
This requires that domains A and B have a trust relationship with domain C. (If there is no trust, see Merge keytabs instead)
In addition to the trust relationships, there's also some requirements to your network infrastructure.
...
Windows user | janedoe@EXAMPLE.LOCAL |
JIRA running at | jira.company.com |
JIRA's Service Principal Name | HTTP/jira.company.com |
JIRA's service account | svc-jira-sso@HQ.COM COM |
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 domains controllers. If firewall prevent this, Kerberos authentication will fail.
...
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.
See Merge keytabs for details.