Skip navigation

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:

  • In step 1, the DC queries the local AD domain partition to find out Alice's global group memberships. These not only include Alice's global group memberships that were assigned to her user account directly, but also the global group memberships that were assigned to one of the global groups Alice belongs to.
  • In step 2, the DC queries the local AD domain partition to find out Alice's universal group memberships. Again, These not only include Alice's universal group memberships that were assigned to her user account directly, but also the universal group memberships that were assigned to one of the universal or global groups Alice belongs to.
  • In step 3, the DC queries the local AD domain partition to find out Alice's domain local group memberships. Once more, these not only include Alice's domain local group memberships that were assigned to her user account directly, but also the domain local group memberships that were assigned to one of the domain local, universal, or global groups Alice belongs to.

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:

  • All authorization data it finds in the PAC of Alice's service ticket. These include Alice's global, universal, and domain local group memberships that were assigned either to her directly or to one of the groups she belongs to.
  • Alice's authorization data that's stored in the local security database (SAM) of the resource server. This includes Alice's local group memberships that were assigned either to her directly or to one of the groups she belongs to.

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:

  • Log off then on to force the generation of a refreshed PAC field.
  • Wait for the automatic TGT renewal (this occurs, by default, every 10 hours)
  • Purge the local Kerberos ticket cache using the klist utility and then re-authenticate to the DC. Kerberos re-authentication happens automatically when a Kerberized application is used.

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.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish