PA-PAC-OPTIONS

What the flag does in a Kerberos ticket

PA-PAC-OPTIONS is part of how Kerberos conveys authorisation-related information inside a service ticket. In Windows environments, that means the ticket can carry privilege context into downstream services, so the flag is not just a protocol detail, it is part of the trust model that determines what a service believes about the user or delegated identity.

The practical significance is that the ticket itself becomes more than a bearer token for authentication. If the PAC-related content is accepted too broadly, or if a service trusts ticket data without checking how it was issued, the result can be over-authorization, confused deputy behaviour, or privilege decisions that do not match the real security posture of the caller.

Why privileged attribute certificate data matters

The Privileged Attribute Certificate, or PAC, is the structure that Windows uses to bundle group membership, privilege and related authorisation data into Kerberos tickets. PA-PAC-OPTIONS is the signal that tells the KDC to include that data, which is why the flag matters wherever access control depends on ticket contents rather than a fresh live lookup.

This design improves performance and makes distributed authorisation practical, but it also creates a dependency on the integrity of the ticketing path. If the PAC is stale, manipulated, stripped, or interpreted inconsistently by different components, a service may make an access decision based on data that no longer reflects the user’s current entitlement state.

Delegation paths and service trust boundaries

PA-PAC-OPTIONS becomes especially important when services act on behalf of users, because delegation can extend the reach of ticket contents beyond the original interactive session. The service receiving the ticket may rely on privilege data that was established earlier in the Kerberos exchange, so any weakness in delegation handling can widen the blast radius of a compromised account or service.

That makes the flag part of a broader trust boundary question: which component is allowed to vouch for the user, which service is allowed to consume that vouching, and whether downstream systems should trust embedded authorisation data or re-validate it. In practice, the risk is not the flag alone, but the combination of ticket delegation, service acceptance rules and the durability of the embedded authorisation context.

What defenders should validate

For defenders, the key question is whether the environment depends on PAC-bearing tickets in a way that is consistent, monitored and limited to the services that genuinely need them. That means understanding which applications consume Kerberos authorisation data, whether those services enforce least privilege, and whether ticket-bearing paths are exposed to unnecessary trust.

When a ticketing flow carries privilege information across multiple hops, defenders should treat it like a policy object as well as an authentication artifact. The useful check is not only whether Kerberos is working, but whether the services that consume the ticket are prepared to handle stale, excessive or mis-scoped authorisation context safely.

Risk and Threat Considerations

Because PA-PAC-OPTIONS influences what authorisation data is embedded in a service ticket, failures here can become privilege escalation or trust abuse issues rather than simple authentication bugs. The main exposure is that a service may accept ticket contents as authoritative when the surrounding delegation path, ticket scope or privilege context is weaker than assumed.

Failure mechanism: An attacker who gains a valid ticket, or compromises a service in the delegation chain, can abuse embedded PAC data, replay trust in downstream services, or exploit inconsistent authorisation handling between Kerberos and the application layer.

Impact: The result can be unauthorised access, privilege inflation, lateral movement through trusted services, or access decisions that outlive the user’s true entitlement state.

Practitioner Guidance

What to watch for: Treat PAC-bearing ticket flows as a governance point for authorization, not just an authentication detail. Services that consume Kerberos authorisation data should be reviewed for how they validate ticket context, how they handle delegation, and whether they depend on embedded privilege data without compensating checks.

Governance implication: Ownership usually spans directory, application and platform teams, because the control question is whether the ticketing path, the delegated service and the consuming application all agree on what access the caller should have. If that chain is unclear, the ticket can become a hidden source of over-privilege.

Practitioner takeaway: If a service makes access decisions from Kerberos ticket contents, verify the full delegation path and the trust assumptions behind that decision before treating the ticket as authoritative.

Related resources from NHI Mgmt Group

• Guide: Tailgating and Piggybacking Guide
• What breaks when preflight OPTIONS requests are not handled correctly?
• What breaks when passwordless programmes keep weak fallback options?
• How do SSO, MFA, and passwordless compare as enterprise authentication options?
• Why do recovery options matter so much in password management?