Q: How does Windows learn about a user's group memberships if the Kerberos logon process involves different Windows domains?

A: Last month I explained how Windows learns about a user’s group memberships during the Windows Kerberos logon process. So how would this work if multiple domains are involved, such as when a user accesses a resource that is located in a domain different from his/her logon domain.

The example below shows a typical multi-domain logon example in a Windows AD forest.

The forest consists of a root domain and two child domains. The user Alice is defined in the account domain and logs on to the account domain from a machine in the same domain (this process is referred to as an interactive or local logon). Alice then decides to access a resource that is located on a server in the resource domain, which this triggers a network (or non-interactive) logon process. In this example, Windows will discover Alice’s group memberships as outlined in the following five steps.

In step 1, Alice authenticates to a local Domain Controller (DC) in her account domain using the Kerberos protocol. During this step, the DC gathers the following authorization data and adds them to Alice’s Ticket-Granting Ticket (TGT):

• Alice’s global group memberships—these can be found in the DC’s local AD domain naming context. These global group memberships not only include the global group memberships that were assigned to Alice directly, but also the global group memberships that were assigned to one of the global groups Alice belongs to.
• Alice’s universal group memberships—these can be found on a Global Catalog (GC) DC or if GC-less logon is enabled in a DC’s local AD domain naming context. These universal group memberships not only include the universal group memberships that were assigned to Alice directly, but also the universal group memberships that were assigned to one of the universal or global groups Alice belongs to.
• Alice’s domain local group memberships—these can be found in the DC’s local AD domain naming context. These not only include the domain local group memberships that were assigned to Alice directly, but also the domain local group memberships that were assigned to one of the domain local, universal, or global groups Alice belongs to.

In step 2, Alice tries to get a service ticket for the resource from her authenticating DC. The DC of the account domain cannot issue such a ticket, and refers Alice to a DC in the root domain using a Kerberos referral message. This message contains a Kerberos referral TGT, which has Alice’s global and universal group memberships embedded in it.

In step 3, the DC of the root domain copies the authorization data in the referral TGT to a new referral TGT. The DC then refers Alice to a DC in the resource domain.

In step 4, the DC of the resource domain constructs a service ticket for Alice. During this step, the DC expands Alice’s domain local group memberships in the resource domain and adds them, together with Alice’s global and universal group memberships (which can be found in the referral TGT), to the newly constructed service ticket. The service ticket is then forwarded to Alice. The domain local groups that are expanded in this step not only include the domain local group memberships that were assigned to Alice directly, but also the domain local group memberships that were assigned to one of the domain local, universal, or global groups Alice belongs to.

In step 5, Alice uses the service ticket to access the resource. The Local Security Authority (LSA) on the resource server will then construct an access token for Alice given Alice’s service ticket and authorization data in the resource server’s local security database (SAM). Alice’s final access token holds the following data:

• Alice’s global group membership from Alice’s definition domain (the account domain), universal group memberships from any domain in the forest, and domain local group memberships from the resource domain (these are all embedded in the service ticket)
• Alice’s local group memberships (the LSA retrieves these from the local SAM on the resource server)