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):

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: