Kerberos PAC validation when the domain controller is unreachable

Kerberos proves that a client holds a service ticket. The Privilege Attribute Certificate inside that ticket carries authorization data such as group membership. A service that trusts the PAC without checking its signatures can accept modified group claims. A service that asks a domain controller to validate every PAC can instead stop authenticating users when the network path to that controller fails.

Know which check is local

The PAC contains a Server Signature that the KDC creates with a key shared with the service, and a KDC signature that protects the authorization data. The service can verify the server signature locally with its key. A policy that requires stronger assurance can forward the PAC signature in a KERB_VERIFY_PAC message to a domain controller for validation.

Those checks answer different questions. Local verification establishes that the PAC is bound to a KDC and service key. Domain-controller validation asks the authoritative Kerberos service to confirm the authorization data. Neither check proves that the account's current group membership is appropriate for a particular application action.

Choose a deliberate failure mode

PAC validation should have explicit behavior for timeout, refusal and a controller that returns no useful answer. Failing open preserves availability for anyone who can present a ticket and defeats the control. Failing closed protects the authorization boundary but can create a broad outage during a domain-controller incident.

Do not hide the decision in a vague retry loop. Define the maximum wait, the set of controllers used and whether cached validation is allowed. If cached results are permitted, set their lifetime and make emergency invalidation possible. Attach the policy to the service or application tier because a payroll system and a read-only intranet page do not have the same tolerance.

Monitor validation errors separately from bad password errors. Distinguish local signature failures, controller timeouts, controller refusals and authorization denials. Those signals lead to different owners and different recovery steps.

Test under realistic failure

Test a valid ticket with one controller unavailable, a forged PAC signature, a valid PAC from an unexpected service key and a group change that occurs during a cached validation window. Record whether the application denies the request, uses a documented cache or returns a distinct error.

Review service-account keys and trust boundaries after the test. A service that can validate any PAC should not also be exposed as a general-purpose application account. Keep the authentication path and the business authorization decision separate so a PAC result cannot silently bypass an object-level permission check.

The operational question is whether an unreachable controller creates a controlled denial or an authorization bypass. The answer should come from configuration and evidence, not from whichever code path happens to return first.

References

• MS-PAC: Server Signature
• MS-APDS: Kerberos PAC Validation