ImmutableID – mS-DS-ConsistencyGuid – AADConnect – ADMT – part 3b

In part 3a, we explained how ADFS can be used in cross-forest migrations to ensure all users (migrated or not) can still authenticate. In part 3B we will be looking at Pass-Through authentication and how it affects migrated/non-migrated users.

First of all, we need to make sure we have pass-through authentication agents deployed. In my environment I already have these agents deployed in the source (FORESTROOT), but not in the target domain. Obviously non-migrated users on the pass-through domain can authenticate.

So in order to first prove that the user is authenticating against the local domain (rather than using password sync), after the login, I checked the Security eventlog on the domain controller:

The event shows that the AzureADConnectAuthenticationAgentService.exe is requesting impersonation.

We can now also deploy additional agents on the target system, in my case I installed the agent on the target domain controller (but obviously you should follow official recommendations). The agent can be downloaded from the portal:

After the installation, I wanted to make sure that the newly deployed agent was able to authenticate my non-migrated users. Similar to how ADFS (see chapter 3a) setup was done. In order to force the new domain controller to authenticate my users, I stopped the agent on the FORESTROOT domain controller.

Now when we try to login to AAD with a non-migrated user, we will still see the following entry in the FORESTROOT domain controller, indicating a successful login. You will actually notice 2 entries in the security eventlog. The first being a 4768 and the second being 4769

These two events basically indicate a cross-forest authentication. What is important to note though is the User ID field in the 4768 event. The username is not represented as a UPN, but with the NETBIOS name. So let’s proceed to move this user to the new domain. Similar to the ADFS setup, I manually set the UPN for the user and ensured the ms-ds-consistencyGuid is the same on the source and migrated objects. The difference between pass-through and ADFS now becomes clear. Until the AADSync synchronizes the data, the user will continue to be authenticated in the source forest. This as the pass-through agents will use the NETBIOS information. This is visible when we look at the export details in the MIIS console for our export to AAD after we migrated the user:

As indicated in yellow, the netBiosName changed to the TARGET domain name. I manually edited the UPN of the user (in capitals for clarity).

In short, AAD will now upon entering a username in the login field, get the netBiosName and validate the user against that.

It is not that only the pass-through agents of the TARGET forest will pick-up the authentication, any agent can pick it up, but it will perform an authentication for NETBIOS\Username using the information known (netBiosName + onPremisesSamAccountName).

So as you can see, even pass-through authentication can be used for authentication to AAD in cross-forest migration scenarios!

Next up is the cross-forest authentications for regular services (like file servers..)

%d bloggers like this: