In short: Kantega SSO can authenticate users in domains A and B using a keytab issued using a service account in domain C.
This requires that domains A and B have a trust relationship with domain C.
In addition to the trust relationships, there are also some requirements for your network infrastructure.
To understand this better, let us consider an example:
Cross-domain authentication example:
First, the facts:
JIRA running at
JIRA's Service Principal Name
JIRA's service account
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.
When Jane attempts to access JIRA, the following happens:
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 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.