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..)
To continue our coverage of ADMT and AAD, part three of the series. I know I promised 3 articles, but given the amount of data, I’ll split part 3 (authentication) in a few more posts..
We have 1 AAD and 2 AD’s; FORESTOOT.local as the source and TARGET.local is still the target AD forest. There is a two-way forest trust between the two forests Forestroot.local is still based on Windows 2016, TARGET is still based on 2012R2. And we continue to have our members server in the target.local domain that functions as the ADMT and AAD Connect server.
This post will dive further into authentication and access as users are migrated from the source to the target.
When looking at ADMT and migrations in combination with AAD, we have two types of authentication that we need to take care of. Firstly, the cross-forest authentication to member servers and resources, and secondly the authentication on AAD itself. In our earlier migrations we ensured that we would authenticate against the AAD itself by synchronizing the passwords and using managed domains, but there are 3 types of authentication possible with AAD, which we will start with.
- Federated Authentication
- Pass-through Authentication
- AAD Based Authentication
With federated authentication, a user that tries to login to AAD will be redirected to a federation server (usually ADFS) and needs to perform an authentication there. Upon successful authentication, a token is provided that the user then provides to AAD to indicate a successful authentication and providing identity proof. It is up to the federation server to authenticate the user (in any form) and provide the token. Basically, AAD doesn’t care how you authenticated, as long as the token the user provides is valid.
In our cross-forest authentication scenario, this comes down to essentially the same as accessing cross forest resources. In our setup, we did not add any UPN suffixes to the TARGET domain nor did we add them to the routing table (as having conflicting UPN suffixes would not be supported). During our user migration (using ADMT) the UPN automatically got updated on the new user object in the TARGET domain to represent target.local.
It is possible to keep the UPN in a scripted ADMT migration, but in our example we will just update the UPN manually for the migrated objects. (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc974436(v=ws.10)) So, after the update, we end-up with two user objects, representing the same user that both have the same UPN.
Given our users need to login with their email (UPN), means that if our federated user wanted to authenticate against the ADFS server hosted in forestroot.net, the server would validate the UPN only at its own forest. This as the UPN routing table in the forest trust has the suffix “forestroot.net” pointing to the forestroot.local forest (this as the UPN suffix was not added to TARGET.local, nor was it added in the UPN suffix routing table on the trust).
Only if users where to change their login name to TARGET\username would the forest trust be applicable. So in order to avoid this situation, we can actually move the ADFS services to the target domain. This way, non-migrated users authenticating with their UPN, would be authenticated against the FORESTROOT.local forest, given their UPN matches the UPN routing suffix in the forest trust. But (migrated) users, who have their UPN set locally (in the target.local forest) can be authenticated by the Target.local domain controllers.
In my demo environment, I’ve setup another federation server in the target.local forest and gave it a new public URL. I’ve also manually set the UPN for my (migrated) user in the target domain to match the UPN of that object in the forestroot.local domain (matching the user’s e-mail address), as well as ensured that the ms-ds-ConsistencyGuid was equal for both objects.
The thing we must do now, is switch the federation service manually on Azure AD for our specific domain. Switching means that all users trying to authenticate with @forestroot.net to Azure AD will be redirected to the target.local ADFS server. Given the forest trust and UPN routing suffix on that trust, users trying to authenticate to the ADFS server and that do not exist in the local domain(!) will be validated over the trust.
(Note that in this case, the ADFS can only look-up UPN’s in its own domain, not forest. Given the UPN forestroot.net was not added on forest level, only domain wide authentication can be performed. Adding forestroot.net to the target forest would result in the UPN suffix routing table disabling the routing for the suffix and therefore render this solution unusable).
In order to change the AAD configuration, I loaded up PowerShell and logged into MSOL and changed the domain federation configuration:
Update-MsolFederatedDomain -DomainName forestroot.net
Next up, is changing the ADFS configuration. By default it will use the objectGUID for validation (see my other entries) and as such, we need to configure ADFS to use the ms-ds-consistencyGuid. You can obviously also have AAD Connect configure this for you. I followed this article.
Now after this is all set, we are ready to go. You can try to login to Offic365 and the main Microsoft AAD page will redirect now to the new ADFS server. There you can login using the migrated account (in the form or TARGET\user, or firstname.lastname@example.org) or you can actually also login still using the original account using FORESTROOT\user. Non-Migrated (@forestroot.net) users will be authenticated based on their UPN over the forest trust.
In short, this article showed you the inner workings of the O365 login. It uses a combination of UPN + ms-ds-ConsistencyGuid which can exist on more than one domain. Using some trickery we can actually move all our users to the new forest while still allowing non-migrated users access to a new ADFS farm to login. Migrated users can continue to use their existing UPN while logging on to the new forest, even though that new forest does not have their UPN suffix officially registered.
I promised I would make three blog post entries.. but will continue in part 3b with the PassThrough Authentication.
Paul Williams talked in his blog about using another attribute from on-premises Ad’s to act as the ImmutableID for Azure Active Directory (http://blog.msresource.net/2014/03/10/windows-azure-active-directory-connector-part-3-immutable-id/)
While making a very detailed blog entry on why and which attribute to choose, there wasn’t a guide on how to make this work in AADSync.
[update 21-Aug-2017: The latest version of Azure AD Connect have the functionality built-in to select the ImmutableID. There is no need to hack the rules manually anymore.. read more about it at: https://blog.azureinfra.com/2017/08/21/immutableid-ms-ds-consistencyguid-adconnect-final-part/]
So a recent project got me thinking about this. In this particular scenario there is already a forest (1 domain) using DirSync to replicate their users to AAD, and the requirement is to prepare for an AD migration, while also adding other users to the same AAD tenant. As usual, user objects might be duplicate between the two forests and we want to use the mS-DS-ConsistencyGuid attribute to be the immutableID.