Q: How does Windows learn about my group memberships when I log on to a Windows forest? How is this authorization data linked to Kerberos authentication traffic?

A: To understand how Windows learns about your group memberships. you must understand how Windows constructs your access token from the information it finds in your Kerberos authentication ticket and in the local Windows security database (the SAM). An important element in this process is the Privilege Attribute Certificate (PAC) field in a Kerberos ticket. Microsoft uses the PAC to include a user's authorization data in Kerberos tickets. These user authorization data include a user's group memberships.

Figure 2 shows a typical Windows single domain setup where we have a user (Alice), her workstation, a resource server, and a set of domain controllers (that are hosting Kerberos KDCs).

In what follows I will explain how Windows constructs the list of Alice's authorization data when she logs on to the domain and accesses a resource on a member server. This process of finding out a user's group memberships is also referred to as group expansion.

When Alice has successfully authenticated to her DC (this is a DC of the domain where Alice's user account is defined), the DC's KDC constructs a Kerberos Ticket Granting Ticket (TGT). To enable the KDC to populate the TGT's PAC field with Alice's authorization data, the DC completes the following steps:

The KDC then stores the authorization data gathered in these three steps in Alice's TGT and forwards the TGT to Alice's workstation. Alice's workstation will automatically cache the TGT in Alice's local Kerberos ticket cache.

To let Alice access a resource located on a member server and to let Alice transparently authenticate to that member server, the Kerberos logic on Alice's workstation will then use Alice's cached TGT to request to the KDC a service ticket for the resource.

If the service ticket request is valid, the KDC will generate a service ticket. To populate the new service ticket's PAC, the KDC copies the authorization data it finds in the PAC of Alice's TGT. The KDC then sends the service ticket to Alice. Again, Alice's workstation will automatically cache the service ticket in Alice's local Kerberos ticket cache.

When Alice accesses the resource on the member server, her workstation's Kerberos logic will use Alice's cached service ticket to authenticate Alice to the member server.

In step 5, the security logic on the resource server generates Alice's access token. The resource server will embed the following authorization data in Alice's access token:

This process shows that within a Windows user login session, the PAC data is copied from a user's TGT to the new service ticket. The DC doesn't refresh the PAC data when a new service ticket is requested. This means that if a user's group memberships change during the user's login session, the user must do one of the following to force the addition of the new authorization data (group memberships) to his/her Kerberos credentials:

A final note: even though Windows doesn't refresh a user's authorization data when a new service ticket is created, it will check whether the user account hasn't been disabled in AD.