A: In the last two months, I explained how Windows learns about a user's group memberships during the Windows Kerberos logon process in a single and a multi-domain Active Directory (AD) setup. (See "Q: How does Windows learn about my group memberships when I log on to a Windows forest? and "Q: How does Windows learn about a user's group memberships if the Kerberos logon process involves different Windows domains? How is this authorization data linked to Kerberos authentication traffic?")
The image below illustrates an NTLM-based logon sequence in a simple multi-forest environment that consists of an account domain in forest A and a resource domain in forest B. Both forests are linked using a two-way external trust relationship.
In the example, Alice is logged on to the account domain and initiates a non-interactive (network) logon to access a resource in the resource domain. In this example, Windows will perform Alice's group expansion as follows:
Steps 1 through 3 show the NTLM handshake:
- In step 1, Alice attempts to access a resource on a resource server in the resource domain. This step includes an NTLM challenge and response exchange between Alice's workstation and the resource server.
- In step 2, the resource server forwards the NTLM response to a DC of the resource domain for validation (remember the NTLM notion of pass-through authentication).
- In step 3, the DC of the resource domain forwards the NTLM response to a DC in the account domain. This is because only DCs in Alice's account domain have a copy of Alice's password hash, and thus only they can validate the NTLM response.
In step 4, the DC of the account domain validates Alice's NTLM response. If the response is valid, Alice is authenticated. The DC will then expand Alice's global and universal group memberships and forward them together with the authentication result to the DC in the resource domain.
In step 5, the DC of the resource domain expands Alice's domain local group memberships in the resource domain. It then forwards the authentication result together with Alice's global and universal groups from the account domain and domain local group memberships from the resource domain to the resource server.
In step 6, the LSA of the resource server constructs an access token for Alice, given the authorization information it got back from the local DC and the authorization data it finds in the local SAM. Alice's final access token holds the following data:
- Alice's global and universal groups from the account domain and domain local group memberships from the resource domain (these were forwarded by the local DC)
- Alice's local group memberships (the LSA retrieves these from the local SAM on the resource server)