Cross domain trust


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:

Windows user


JIRA running at

JIRA's Service Principal Name


JIRA's service account


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.

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/

  • 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/

  • 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.