Kerberos Privilege Attribute Certificate (PAC)

What the PAC Does in a Kerberos Logon Flow

The PAC is the part of a Kerberos ticket that carries authorisation data, so the ticket can do more than prove that the user authenticated. In Windows environments, that data is used to assemble the user’s access token and determine which privileges, groups, and claims travel with the session.

That makes the PAC a bridge between authentication and authorisation. A valid ticket without trustworthy PAC contents can still create the wrong access decision if the receiving service or directory infrastructure accepts the embedded authorisation data at face value.

Why PAC Contents Matter for Access Decisions

The practical value of the PAC is that it lets Kerberos move group membership and related attributes with the ticket instead of forcing every service to query directory data independently. That improves performance and consistency, but it also means the ticket becomes a carrier for security-critical claims that influence access throughout the session.

Because the PAC contributes to token construction, its contents can affect what a user can open, modify, or administer after logon. The security question is not just whether the ticket is valid, but whether the embedded authorisation data is correct, current, and trusted by the systems that consume it.

PAC Validation and Trust Boundaries

PAC handling is a trust-boundary problem. The service that receives the ticket must rely on Kerberos and the surrounding domain infrastructure to ensure the PAC was issued legitimately and has not been altered in transit or accepted in an unsafe context.

Where validation is weak, a forged or replayed ticket can carry authorisation data that grants unintended access. The risk is especially material in environments where services make privilege decisions based on PAC contents without additional checks on the account, device, or request context.

Kerberos Security Guide is the most direct place to see how PAC validation fits into the wider Kerberos attack surface, including ticket abuse patterns and KRBTGT-related recovery.

Operational Consequences for Windows Domains

In Windows domains, the PAC is central to day-to-day authorisation because it helps determine what a session can do after interactive or service logon. That means PAC-related failures can look like ordinary access issues, over-permissioning, or inconsistent group-based authorisation rather than a clear authentication break.

The operational consequence is that PAC problems often surface as identity and access anomalies, not as obvious Kerberos outages. When PAC data is stale or misvalidated, the result can be excessive access, broken access, or privilege decisions that no longer match directory reality.

PKI Basics Guide helps explain the trust and validation model that underpins ticket and certificate-based trust systems, which is useful context for understanding why validation discipline matters.

Risk and Threat Considerations

The PAC is attractive to attackers because it carries authorisation data that can be abused if a ticket is forged, replayed, or accepted without sufficient validation. If an adversary can influence ticket contents or exploit weak trust checks, they may obtain more access than the directory or account would normally allow.

Failure mechanism: Weak PAC validation, stale authorisation data, or ticket forgery can let a service build an access token from untrusted claims and group memberships.

Impact: The result can be privilege escalation, unauthorized access to internal services, and broader domain compromise if privileged sessions or administrative paths inherit the bad decision.

Practitioner Guidance

Why practitioners should care: PAC issues are often invisible until an access decision goes wrong, so they belong in the same review path as Kerberos trust, ticket integrity, and domain privilege boundaries. Treat PAC handling as part of the authorisation control plane, not just a Kerberos implementation detail.

What to watch for: Pay attention to unusual group-based privilege assignment, unexpected token contents, and services that assume the PAC is inherently trustworthy without any compensating validation or review.

Related resources from NHI Mgmt Group

• Privilege Attribute Certificate
• How should security teams reduce the risk of privilege escalation through Kerberos certificate abuse in Active Directory?
• How does a privilege attribute certificate work?
• Who is accountable when a certificate validation bug enables privilege escalation?