Kerberos Unlocked (Part 4): How Authorization Works

In the previous posts we saw how clients obtain a TGT and Service tickets, each of which can include an authorization-data field. In this article we’ll unpack that field and the PAC (Privilege Attribute Certificate) it often contains. You’ll learn what the PAC holds, how it’s carried inside a Kerberos ticket, how Windows services validate it, and why it’s central to authorization.

Authentication VS Authorization

Authentication is the process of verifying a user's identity to confirm they are who they claim to be, like showing a passport to check into a hotel.

Authorization however is the process that determines what resources or actions an authenticated user is allowed to access or perform, such as getting a hotel key card that only grants access to a specific room.

After authenticating to a service the service has to determine what resources you have access to and what actions you perform.

This image provides an simple example of Authorization:

The authorization-data field:

The authorization-data field is included in both the Ticket-Granting Ticket (TGT) and in every Service Ticket. As its name suggests, this field is designed to hold authorization-related information about the client.

In a Windows Active Directory environment, its most important role is to carry the PAC. [EXPLAINED BELOW].

Structure of the authorization-data field:

1. ad-type → This field specifies the format for the ad-data field. This tells the service how the ad-data field should be interpreted. [EXPLAINED BELOW]
2. ad-data → Contains the actual authorization information. [EXPLAINED BELOW]

Visual Representation of the authorization-data field:

ad-type field:

This field holds an integer value that specifies the type and format of the associated ad-data field. In other words, it identifies how the ad-data should be interpreted by the service.

This field could have many values, the one we are interested in is this one:

1. AD-IF-RELEVANT → Authorization Data of this type is only intended to be interpreted (or be processed) by the services that understands it. Services that do not understand this type can safely ignore it. The integer value used in ad-type for this is (1).

Although this field could have many values, the only ad-type we need to focus on for now is AD-IF-RELEVANT, because in Windows environments the PAC is carried inside the ad-data field of this type.

ad-data field:

The ad-data field contains the actual authorization information. How this data is formatted and interpreted depends on the ad-type value it is associated with.

As mentioned above, the only type we will focus on is AD-IF-RELEVANT.

If the ad-type for this associated data is AD-IF-RELEVANT then the data will carry another authorization-data structure nested inside it. I know its getting a bit confusing look at the visual image below to understand it further.

Visual Representation:

As shown in the image above, the nested authorization-data inside the outer ad-data carries an ad-type of AD-WIN2K-PAC. This value is specific to Windows and was not covered earlier. The ad-data for this type is what contains the actual PAC.

PAC:

The Privilege Attribute Certificate (PAC) is used in Windows, and it carries the user's Authorization information. It includes details such as the user’s group memberships, profile and policy settings, and other supporting security metadata.

The PAC itself is made up of a number of different structures, each carrying specific pieces of authorization-related information. While all of these structures play a role in the broader authorization process, the most important one — the structure that services mostly rely on to decide whether a user can access a resource or perform a task — is the Logon Information structure (KERB_VALIDATION_INFO).

Logon Information structure (inside the PAC):

This structure has more then 35 values so i will only cover the important ones here.

1. LogonTime → Contains the user's last logon time.
2. LogoffTime → Contains the time when the client's Logon session is set to expire.
3. EffectiveName → Contains the user account's samAccountName attribute.
4. UserId →  Contains the RID of the account.
5. PrimaryGroupId → Contains the RID for the primary group to which this account belongs (it is mostly the RID for the Domain Users group, unless changed).
6. GroupCount → Contains the number of groups (from the same domain as the user) the user is part of, eg. (Domain Admins, RDP Users, etc).
7. GroupIds → Contains the groups(basically the RID of those groups) to which the account belongs in the account domain. The number of groups in this list MUST be equal to GroupCount.

I only covered the basic fields of this structure here, as i said it has more then 35 fields. Check out microsoft documentation for more details.

Service Checksum Structure:

This structure is inside the PAC and it helps the Service verify that the PAC was actually generated by the KDC and has not been tampered.

1. Type → Indicates the cryptographic algorithm used to generate the checksum(e.g., HMAC-MD5, HMAC-SHA1-96 with AES128/256).
2. Signature → This contains the checksum of the whole PAC message generated using the Service Long-term key. This checksum is generated by the KDC, when it provide the client with an PAC.

When a service receives a ticket, it takes the PAC data and computes its own checksum using its long-term key. If this locally computed checksum matches the one stored in the PAC’s Server Checksum structure, the service can trust that the PAC has not been altered.

Ticket Checksum Structure:

This structure is used by the KDC to verify that the Service Ticket was not tampered.

1. Type → Indicates the cryptographic algorithm used to generate the checksum(e.g., HMAC-MD5, HMAC-SHA1-96 with AES128/256).
2. Signature → This contains the checksum of the enc-part of a Service Ticket, it is generated using the KRBTGT Long-term key. This checksum is generated by the KDC, when it provide the client with an PAC.

When a Service Ticket is later presented to the KDC — for example, during renewal or when it is forwarded - the KDC takes enc-part of the Service ticket and computes its own checksum using the KRBTGT long term key. If this locally computed checksum matches the one stored in the PAC’s Ticket Checksum Structure, the KDC can be sure that the Service Ticket was not altered.

Privsvr Checksum Structure:

This structure is used by the KDC to prove that the Server Checksum Signature was generated by a trusted KDC.

1. Type → Indicates the cryptographic algorithm used to generate the checksum(e.g., HMAC-MD5, HMAC-SHA1-96 with AES128/256).
2. Signature → This contains the checksum of the Service Checksum Signature (the signature in the Service Checksum Structure), it is generated using the KRBTGT Long-term key. This checksum is generated by the KDC, when it provide the client with an PAC.

When a service cannot verify the PAC on its own (for example, if the Server Checksum Structure is missing or empty), it can ask a Domain Controller to validate it. The DC then recomputes the checksum of the Server Signature using its KRBTGT long-term key and compares the result with the value stored in the Privsvr Signature structure. If they match, the DC confirms to the service that the PAC was indeed generated by a trusted KDC.

Visual Representation of the Structures in PAC:

I’ve kept this post short and focused so it’s easier to digest. In the upcoming parts, we’ll the different ways Kerberos can be attacked.

I’d really appreciate your feedback and thoughts — they’ll help me improve as I continue this series.

https://x.com/beacon_bytes