Connect
Updated on September 10, 2025
Within Windows Active Directory environments, the Privileged Attribute Certificate (PAC) serves as a critical bridge between authentication and authorization. While Kerberos proves a user’s identity, the PAC provides the authorization data that services need to determine what that authenticated user can actually do.
This data structure eliminates the need for separate queries to Active Directory for every authorization decision. Instead, it embeds a user’s group memberships and privileges directly into their Kerberos tickets. The result is a more efficient authentication system that maintains security while reducing network overhead.
Understanding the PAC becomes essential when troubleshooting authentication issues, implementing security controls, or analyzing potential attack vectors in enterprise environments.
How to Modernize Your AD Instance
The IT Professional’s Roadmap to Augmenting or Replacing AD
Definition and Core Concepts
A Privileged Attribute Certificate (PAC) is a cryptographically signed data structure embedded within Kerberos tickets. It contains a user’s complete security context, including their Security Identifier (SID) and the SIDs of all groups they belong to.
The Authentication vs. Authorization Divide
Kerberos handles authentication—the process of proving identity. Active Directory manages authorization—defining what permissions an identity possesses. The PAC securely transfers authorization data from Active Directory into the Kerberos authentication flow.
This separation allows services to make authorization decisions without querying Active Directory directly. The PAC ensures that all necessary permission data travels with the user’s credentials.
Security Identifier (SID) Foundation
The SID serves as the foundation of Windows security. Each user, group, and computer receives a unique, immutable SID that identifies them across the entire domain.
The PAC functions as a secure container for these SIDs. It packages the user’s SID along with all group SIDs they belong to, creating a complete authorization profile within the ticket itself.
How PAC Works in the Kerberos Flow
The PAC integrates seamlessly into the standard Kerberos authentication process, adding authorization data at key points in the ticket exchange.
TGT Issuance Process
When a user logs into a Windows domain, the authentication process follows these steps:
The Kerberos Key Distribution Center (KDC) first authenticates the user’s credentials. Once authentication succeeds, the KDC queries Active Directory to retrieve the user’s SID and all group SIDs they belong to.
This authorization data gets packaged into a PAC structure. The KDC then signs the PAC using the krbtgt account’s password hash—a critical security step that prevents tampering.
The signed PAC embeds directly into the user’s Ticket-Granting Ticket (TGT). This TGT now contains both authentication proof and authorization data in a single, secure package.
Service Ticket Creation
When users request access to specific services, the process streamlines significantly:
The user presents their TGT to request a Service Ticket. The KDC copies the existing, signed PAC from the TGT and embeds it into the new Service Ticket. No additional Active Directory queries occur at this stage.
This design prevents the KDC from becoming a bottleneck, as it doesn’t need to re-query authorization data for every service request.
Service-Side Verification
Target services handle PAC validation through a straightforward process:
The client presents the Service Ticket containing the embedded PAC. The service decrypts its portion of the ticket using its own service key. The service validates the PAC’s cryptographic signature to ensure integrity.
Once validated, the service extracts the SIDs from the PAC and uses them for access control decisions on its resources. No communication with Active Directory is required for these authorization checks.
Key Security Features
Cryptographic Integrity
The PAC’s security relies on its cryptographic signature created with the krbtgt account’s password hash. This signature serves multiple critical functions.
It prevents attackers from modifying group memberships within a ticket. Any alteration to the PAC invalidates the signature, causing authentication to fail. Services can trust that the authorization data hasn’t been tampered with during transmission.
The signature also prevents privilege escalation attacks where attackers might attempt to add themselves to administrative groups by modifying ticket contents.
Performance Optimization
The PAC eliminates authorization bottlenecks in several ways:
Services avoid making LDAP queries to domain controllers for every access decision. Network traffic reduces significantly, especially in environments with frequent authorization checks. Domain controllers experience lower load since they only need to provide authorization data during initial authentication.
This efficiency becomes particularly important in large environments where thousands of authorization decisions occur every minute.
Breaking Up with Active Directory
Don’t let your directory hold you back. Learn why it’s time to break up with AD.
Troubleshooting and Security Considerations
PAC Validation Failures
When PAC validation fails, authentication typically fails entirely. Common causes include:
Corrupted tickets due to network issues or storage problems. Clock synchronization problems between client, service, and domain controller. Compromised krbtgt account passwords requiring immediate attention.
These failures often manifest as “The security database on the server does not have a computer account for this workstation trust relationship” or similar authentication errors.
Historical Vulnerabilities
The PAC has been targeted by several high-profile attacks throughout its history. These vulnerabilities typically involve:
Signature validation bypasses that allow attackers to forge PACs. Privilege escalation attacks where attackers grant themselves administrative rights. Cross-domain trust exploitation in multi-forest environments.
While specific exploitation details remain outside this discussion’s scope, these vulnerabilities highlight the importance of keeping domain controllers updated and monitoring for unusual authentication patterns.
Cross-Domain Trust Considerations
In environments with domain trusts, PAC handling becomes more complex:
The trusted domain’s domain controller re-signs the PAC when users cross domain boundaries. This process ensures that authorization data remains valid and trusted in the new domain. Additional validation steps occur to prevent cross-domain privilege escalation attacks.
Understanding this process becomes crucial when troubleshooting authentication issues in complex, multi-domain environments.
Key Terms Reference
- Privileged Attribute Certificate (PAC): Data structure within Kerberos tickets containing authorization information including user and group SIDs.
- Kerberos: Network authentication protocol that proves user identity through cryptographic tickets.
- Active Directory: Microsoft’s directory service that manages user accounts, groups, and authorization policies.
- Security Identifier (SID): Unique, immutable identifier assigned to users, groups, and computers in Windows environments.
- Ticket-Granting Ticket (TGT): Initial Kerberos ticket containing user authentication proof and embedded PAC data.
- Key Distribution Center (KDC): Kerberos service running on domain controllers that issues and validates authentication tickets.
