Cross-domain access: Kerberos referrals, SIDHistory, SID filtering, and selective authentication

1. Core mechanism

This lesson separates cross-domain Kerberos access into referral, PAC/SID filtering, selective-authentication, and resource-ACL layers. They are decision/triage gates, not a claim about a fixed internal wire order for filtering and selective-authentication checks inside the target KDC. The model keeps the ticket and KDC reply enc-part as sibling fields.

Interfaces and specifications

• Referral TGT: a krbtgt/FOREIGN-REALM ticket that the local KDC can issue so the client can contact the target realm’s KDC.
• TDO inter-realm trust information: directory data the KDC uses for cross-domain referrals and trust-key operations.
• PAC ExtraSids and SIDHistory: authorization data that can carry additional SIDs, including historical SIDs retained during migration.
• SID filtering: trust-boundary processing that can remove SID classes from PAC authorization data or reject authentication, depending on the trust and SID class.
• Selective authentication: a trust mode that requires the principal to have the Allowed-to-Authenticate control-access right on the target object.
• Allowed-to-Authenticate rights GUID: 68b1d179-0d15-4d4f-ab71-46152e79a7bc.
• Resource ACL: the target object’s permissions determine whether an authenticated principal may perform the requested operation.

A referral is not the destination service ticket

When a client requests a service principal name (SPN) in another domain, its local KDC may return a referral TGT for the target realm instead of the final service ticket. The client then sends a new TGS-REQ to the target KDC using that referral.

The KDC reply has separate ticket [5] and enc-part [6] fields. The client obtains the new session key from the reply enc-part: for a TGS reply, it uses the authenticator sub-session key if supplied, otherwise the session key of the TGT used in the request. This does not decrypt the returned ticket; the referral ticket and ordinary service ticket have their own recipient-key protection.

SIDHistory provides continuity, but is not an unlimited passport

An object’s objectSid identifies it in its current domain. After a cross-domain move, sIDHistory can retain the previous SID so that access to legacy resources can continue during migration. Historical SIDs can be represented in authorization data such as the PAC.

A trust boundary does not have to accept every SID in that authorization data. MS-PAC SID-filtering rules can remove SIDs or reject authentication according to the trust type and SID class. The presence of an sIDHistory value in the directory therefore does not guarantee that the SID will be accepted for authorization in the target domain.

Selective authentication is a separate gate

With forest-wide or domain-wide authentication, a trusted principal may attempt authentication to resources within the applicable scope; this does not grant access to those resources. With selective authentication, the principal also needs the Allowed-to-Authenticate control-access right on the target computer or service account.

Allowed-to-Authenticate permits the target authentication attempt; it does not grant file, share or database access. The client must still present its ticket and the service must accept it before the requested resource right is evaluated. Troubleshooting therefore separates the referral/TGS chain, target-KDC trust/PAC controls, service acceptance and resource authorization. This lesson does not prescribe a fixed internal order for the target KDC’s filtering and selective-authentication checks.

State and data flow

1. If a cross-domain referral is needed, the source-domain KDC uses trust information from its TDO and returns a referral TGT.
2. The client uses the referral TGT to send a new TGS-REQ to the target-domain KDC.
3. While processing the target TGS request, the target KDC evaluates trust-boundary/PAC SID filtering and, when configured, the Allowed-to-Authenticate control-access check on the target computer/service; no fixed internal order is assumed.
4. The target KDC issues a service ticket or rejects the request; 4769 is a KDC-side TGS request/result observation.
5. The client presents the issued service ticket to FS-B. The service evaluates authentication; an issued ticket alone does not establish service acceptance.
6. After service acceptance, the resource evaluates the requested right. Permission on Reports remains separate from accepting the ticket; the fixture does not perform real file access.

2. Exploitation

Broken trust assumption

The attacker has already obtained significant control in a trusted domain, such as the ability to manage trust settings or write SIDHistory. No SID injection is performed on a real system.

Technical prerequisites

• Trust filtering is weaker than the intended baseline or has been relaxed.
• The target resource grants access to an old or overly broad SID, or Allowed-to-Authenticate scope is unnecessarily broad.

Exploitation mechanism

SIDHistory can preserve migration access by carrying a historical SID in authorization data. If trust filtering permits that SID and the target resource ACL grants it access, the authorization path may remain effective. Selective authentication can narrow which principals may attempt authentication to a target, but neither it nor SID filtering replaces the resource ACL.

Do not mistake one gate for complete access

A referral only advances the client to the target KDC. A target service ticket shows that the KDC issued a ticket; it does not by itself prove that the target service accepted it or that the requested resource operation succeeded.

Relaxing SID filtering for a migration can increase the impact of compromise in the trusted domain. Any exception should be limited to the migration scope and duration, tied to an inventory of the relevant SIDs, and paired with review of target ACLs.

3. Defense & Detection

Telemetry scope

• Triage cross-domain failures by checking the referral path, target TGS request, target-KDC PAC/SID filtering and selective-authentication checks, and then resource authorization as separate layers; do not assume a fixed internal check order.
• Inventory principals with SIDHistory alongside the migration owner, source SID, and planned removal date.
• Verify trust attributes and SID-filtering posture at both ends of the relationship.
• Review Allowed-to-Authenticate ACEs on target computer or service objects and keep their group scope narrow.

Events and relevant fields

• Event 4769 is a KDC-side TGS request/result observation generated on a domain controller. It does not prove that the target service accepted the ticket or that the resource ACL allowed the operation.
• The native 4769 XML result field is Status; Event Viewer may label it Failure Code. Interpret ServiceName, TargetDomainName and other fields against the published schema for that OS/event Version; do not mistake a collector-mapped name for the native XML name.

Separate the failure layer from the ticket chain

If the source KDC does not return the expected referral, check trust-path and name-routing context. If the target KDC rejects the target TGS request, review the relevant trust key/TDO, SID-filtering outcome, and selective-authentication configuration. If a service ticket is issued but the service rejects it, investigate ticket acceptance and service-side policy; if the ticket is accepted but the requested operation is denied, inspect resource authorization.

This layer-by-layer diagnosis helps avoid changing trust settings without evidence.

Detection logic · XPath

*[System[(EventID=4769)]]

Query assumptions

• Event 4769 observes a DC-side TGS request/result. Event ID alone does not distinguish referral and final target-TGS records in the same cross-domain flow; field and trust-context enrichment is needed.
• Windows Server 2016 and later may emit Event 4769 Version 2 after the January 14, 2025 update. Interpret fields using the event version and operating-system schema.
• This query was not run against a live Windows dataset, and the lesson artifact contains no Event 4769 record.

False positives

• Normal cross-domain application use can produce multiple 4769 events for referral and final TGS requests.
• A successful 4769 indicates ticket issuance, not target-service acceptance or resource-ACL success.

Hardening

• Keep SID filtering at the secure baseline appropriate to the trust type; time-limit and scope any migration exception.
• Assign an owner, source SID, and removal date to each SIDHistory migration entry.
• When selective authentication is enabled, grant Allowed-to-Authenticate only to groups that need to authenticate to the target.
• Review target ACLs for broad foreign principals and grant access through narrowly scoped groups.

Read the examples

O:BAG:BAD:(OA;;CR;68b1d179-0d15-4d4f-ab71-46152e79a7bc;;S-1-5-21-1987654321-1234567890-2468013579-4206)

Two reality checks

Assumption: Receiving a referral TGT means access to the target resource is complete.

In fact: A referral only lets the client contact the target KDC. Target TGS processing, service acceptance, selective authentication where configured, and resource authorization remain distinct checks.

Assumption: Every SIDHistory value is carried through every forest trust into the target token.

In fact: No. MS-PAC SID-filtering rules may remove SID classes or reject authentication depending on the trust and SID class.

Sources

• Microsoft Open Specifications · Cross-Domain Trust and Referrals
  TDO referral key; cross-organization ACL check occurs while processing the target TGS request.
• Microsoft Open Specifications · SID Filtering and Claims Transformation
  Trust-boundary classes and SID filtering decisions.
• Microsoft Open Specifications · KERB_VALIDATION_INFO
  ExtraSids in the PAC validation information and their authorization-data role.
• Microsoft · Planning for compromise
  SIDHistory in migration and historical SID population of access tokens.
• Microsoft · Allowed-To-Authenticate extended right
  Rights GUID 68b1d179-0d15-4d4f-ab71-46152e79a7bc and target control-access scope.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  DC-only TGS request/result event; Version 2 after January 14, 2025 update on supported systems; event does not prove target service acceptance.
• IETF RFC 4120 · Kerberos V5
  Sections 5.4.2 (ticket [5] and enc-part [6] siblings) and 3.3.4 (TGS reply key); sections 3.2.3 and 1.4 (application-server authentication is not resource authorization).