PAC_REQUESTOR is a new Kerberos PAC data structure that records the requestor identity tied to the ticket. During validation, the domain controller checks whether the username maps to the same SID in the PAC_REQUESTOR field, helping detect forged or mismatched tickets.
PAC_REQUESTOR as a Kerberos ticket integrity check
PAC_REQUESTOR is a Kerberos PAC field that ties a ticket to the requestor identity seen at issuance time. Its purpose is narrow but important: it gives the domain controller another way to verify that the username presented during validation corresponds to the same SID recorded in the ticket context.
That makes the structure part of ticket provenance rather than a general access-control feature. It helps the validator compare what the ticket claims with what the account directory says should be true, which is especially useful when the ticket lifecycle is being challenged by forgery, replay, or account mismatch conditions.
How PAC_REQUESTOR fits into Kerberos validation
In Kerberos, the PAC already carries authorization data that helps a service or domain controller reason about the authenticated principal. PAC_REQUESTOR adds a requestor binding, so the validator can check whether the requesting username maps to the expected SID in the PAC_REQUESTOR field before relying on the ticket.
This extra comparison does not replace Kerberos authentication, it strengthens validation around the ticket’s identity assertions. The practical value is in detecting cases where a forged ticket, a mismatched principal, or tampered PAC data would otherwise look superficially valid.
Because the check is performed during ticket validation, it sits at a trust boundary where directory consistency, PAC integrity, and account identity all need to line up. When they do not, the mismatch itself becomes a signal that the ticket should not be trusted at face value.
Security implications of requestor binding
PAC_REQUESTOR matters because ticket forgery and ticket manipulation are not limited to breaking cryptography outright. Attackers often try to reuse, alter, or mint credential artifacts that still appear plausible to downstream services, so any field that anchors the ticket to a real requestor identity improves detection.
That also means operational drift can surface as a security symptom. If the account behind a request no longer maps cleanly to the SID expected by the PAC, the issue may reflect stale identity data, account renaming, or a more serious integrity problem in the ticket path.
Where the term is used and why it matters in practice
PAC_REQUESTOR is relevant wherever Kerberos tickets are validated against directory-backed identity data, especially in Windows domain environments. It is most useful to people who need to understand why a ticket was accepted or rejected, and how the PAC contributes to that decision.
For defenders, the term is a reminder that authentication artifacts are not just opaque blobs. They carry internal consistency checks, and those checks can become part of the evidence chain when investigating suspicious ticket behaviour or mismatched principal data.
The broader lesson is that Kerberos trust depends on both cryptographic validity and identity consistency. PAC_REQUESTOR strengthens the second part of that equation by making the requestor visible to validation logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Kerberos ticket validation supports organizational user authentication assurance. |
| IA-5 — Authenticator Management | PAC_REQUESTOR strengthens reliance on ticket-related authentication material. | |
| AU-2 — Event Logging | Ticket validation and mismatch detection benefit from audit visibility over authentication events. | |
| Recommendation — Use IA-2 to ensure ticket-based authentication is validated against authoritative identities. Apply IA-5 to manage Kerberos credentials and related authentication artifacts tightly. Log Kerberos validation failures and identity mismatches for investigation and correlation. | ||
Related resources from NHI Mgmt Group
- Why does enforcing PAC requestor validation reduce Golden Ticket risk in Active Directory?
- Why do identity vulnerability assessment programmes need both requestor and customer details?
- What is the difference between a Token Service Provider and a Token Requestor?
- What are the signs that PAC is failing to protect a code path in practice?
