Cross domain trust

Background

Kerberos supports authentication across domain and forest trusts. (See How Domain and Forest Trust Work from Microsoft)

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:

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.