Q: How do a user's group memberships work during logon in single- and multi-domain Active Directory (AD) setups using the NTLM protocol?

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