Greetings all. I’m working with a client that had an existing forest synced to O365 without issue. The client has a compliance mandate that required creating a separate forest and creating certain existing users in the new completely separate domain. These users were not migrated but rather exist as new entities with different UPNs in the new forest. There is no trust between them nor can one be created for security reasons.
The decision was made to attempt to run Azure Ad Connect in the new forest as that will be the more secure location and have that ADConnect instance talk to both forests using the appropriate credentials. This existing AD Connect services in the original domain were stopped and a new AD Connect VM created in the new domain. The new instance was originally configured to touch only certain test OUs in the old and new domain to validate the behavior.
The new instance was originally configured for staging mode and during setup AD Connect was told to use the Mail attribute to identify users across the domains. In this case, the users have different UPNs but the same E-mail in both places. We do not want the O365 UPNs/logins changed.
Testing this in staging mode looked promising as we could see the results from the old domain and the new that were to be pushed to the AAD connector. However, when we took it out of staging mode we could get simple updates to a department or phone number to propagate to the tenant.
In our case, the users who were in the old domain and now re-created in the new were disabled in the old domain. The rules editor shows that all default rules for the new domain have a lower precedence than the rules for the old domain. We were frustrated – for example – to see that the disabled user in the old domain apparently results in a blocked O365 sign in even though the new domain’s user is enabled? Even re-enabling the account in the original domain did not revert this sign status to unblocked?
At one point we attempted to filter off the old domain users and just have AD Connect process the new domain but this resulted in “attribute must be unique” errors when trying to sync to O365. Apparently the sync tool is seeing a proxy address on a user in the new domain as well as the existing cloud user and assuming there is a clash.
BTW we are running 1.1.614 on a serve 2012R2 VM.
At this point we’re at a loss. The goal was to have the users in both domains be identified to AD Connect as the same person and then sync these attributes to the one user in the common tenant. As I mentioned, what we are seeing is that changes to the user in the new domain do not appear to be propagating to the tenant even though there is no error at the sync server.
To be fair, we are making changes in AD, then manually running either delta or full imports followed by delta or full syncs and then checking back with the tenant. Even after 15 minutes and logging out of and back into the portal we are not seeing the updates we would expect to see.
I’m hoping someone can provide guidance as to how best to configure AD connect for a situation in which we have the same user in two places trying to sync back to a common tenant. We did call support but that was a frustrating experience as the language barrier and misunderstanding of the criteria resulted in the 1st level engineer simply stating that we could not do this. We escalated to his support supervisor who then took numerous screen shots and collected additional data but then came back the next day and said the UPNs in the tenant would have to be changed?
Again, maybe that’s the answer but I’m holding the vendor to their documented statements:
Two forests, one AD Connect and one tenant is supported
There is a method to identify and “join” entities in the two forests
The system can reconcile differences based on precedence in the ruleset and update the user in the tenant accordingly.
Well, I understand what you mean and indeed there is only one O365/Azure AD account in use but if there is no supported way to handle multiple forests with non-unique users why then does the AD Connect wizard offer a step of selecting an attribute to identify users in multiple places? Why then are there precedence rules that dictate which order conflicting attributes are to be resolved?
This is part of our problem. MS support has already stated that we cannot do this without changing the UPNs of the non-unique users in O365. We do not want to do this and all of the relevant documentation and support/blog posts I'm reading suggest that this scenario should work.
If it is in fact not supported I really wish MS would update their guidance to clearly and specifically spell this out.
If we cannot get past this our solution will be to filter off the users in the original domain altogether and then manually map the users in the new domain to the existing O365 users.