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 email@example.com) 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.