Domain and forest trust

Owned by Steinar Line
Last updated: Sept 18, 2024 by August Heltne
2 min read

Background

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

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. (If there is no trust, see Merge keytabs instead)

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

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 

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.

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. 

What when there is no trust?

If domains A and B are 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 on how to set up this.