Kerberos Authentication Across Explicit Trusts in Windows 2000

In Microsoft Windows 2000, Kerberos version 5 serves as the primary security protocol for distributed authentication. When a user needs access to resources located in a different domain connected by an explicit trust—such as a shortcut trust—the Windows 2000 Key Distribution Center (KDC) bypasses the standard hierarchical trust path. Instead, it issues cross-realm referral tickets directly between the involved domains using a shared inter-realm trust key, significantly reducing authentication latency and domain controller traffic.

The Role of Explicit Trusts in Windows 2000

In an Active Directory forest, domains are naturally linked through two-way, transitive tree-root or parent-child trusts. When two domains are separated by multiple intermediate nodes in the domain tree, traversing the hierarchy step-by-step can introduce noticeable delays.

An explicit trust (often configured as an external trust or shortcut trust) establishes a direct, non-hierarchical relationship between two specific domains. When an explicit trust exists, Windows 2000 configures an inter-domain trust account and a shared secret key (trust password) between the domains, allowing direct inter-realm Kerberos referrals.

Step-by-Step Authentication Process

When a client in Domain A requests access to a network resource in Domain B via an explicit trust, Windows 2000 processes the request through the following sequence:

1. Service Ticket Request (TGS-REQ)

The user, already authenticated in their home domain (Domain A), holds a valid Ticket-Granting Ticket (TGT) from Domain A's KDC. When attempting to access a service in Domain B, the client sends a TGS-REQ to Domain A's KDC requesting a session ticket for the target Service Principal Name (SPN).

2. Issuing the Inter-Realm Referral Ticket (TGS-REP)

Domain A's KDC evaluates the SPN and determines that the target account does not reside locally. The KDC queries Active Directory, identifies the explicit trust relationship with Domain B, and generates a cross-realm referral TGT rather than routing the request up the domain tree hierarchy.

This referral ticket contains:

  • The client's identity and Privilege Attribute Certificate (PAC), which lists group memberships.
  • An authorization payload encrypted using the inter-realm trust key shared exclusively between Domain A and Domain B.

3. Referral Presentation to the Target Domain KDC

Domain A's KDC returns the referral TGT to the client workstation. The client's Kerberos security provider extracts the ticket and connects directly to a KDC in Domain B, presenting the referral ticket along with a request for a service ticket targeting the final resource.

4. Validation and Service Ticket Issuance

The KDC in Domain B receives the referral ticket and decrypts it using its copy of the shared inter-realm trust key. Because decryption succeeds, Domain B's KDC trusts the authentication performed by Domain A.

The KDC in Domain B then:

  • Extracts the user's security identifiers (SIDs) from the PAC.
  • Appends any local group memberships or SID filtering attributes applicable in Domain B.
  • Encrypts a new service ticket using the target service account's secret key.
  • Returns the service ticket to the client workstation.

5. Accessing the Resource

The client workstation presents the final service ticket directly to the target server hosting the requested service. The server decrypts the ticket using its local secret key, validates the user's PAC, and determines resource access permissions according to its configured Discretionary Access Control Lists (DACLs).