This blog is to demonstrate how we can have one on-premise user synced with two different office 365 tenants, this was done for testing purposes only and is not supported.
The idea of this testing is to have one user account on a local active directory server but synced across two separate tenants using two AAD connect servers. Each of the AAD connect servers will be configured to use different source anchors from each other and also sync different attributes across the tenants so there should be no attribute writeback clash cross tenant. A transformation rule will be set on both AAD connects to sync a unique UPN which is relevant on the office 365
Two tenants used for testing:
@tsdemotest1.onmicrosoft.com
@tsdemotest2.onmicrosoft.com
Three user accounts have been created for sync testing:
Three user accounts have been created for sync testing:
AAD connect installed on syncserver1 with the following custom options:
As expected the users are synced to office 365 with an onmicrosoft account due to vanity domain not available
On Active Directory the attribute is written back
AAD connect was now installed on syncserver2 with the source anchor changed to ms-ds-consistencyGUID
After the second AAD connect box has been configured and using a different source anchor we can see the same user account synced to both tenants
To test the sync works on both the display name for Synced User3 was modified and delta sync ran on both AAD connect servers
Each of the user accounts in active directory now have unique attributes
User account ‘Synced User1’ has been licenced on both tenants and the password has been reset on the local active directory, the user account can log into both email address through OWA as expected using the password changed on-premise
Password writeback has now been enabled on both of the syncservers to check the behaviour of changing the password in one tenant and if it reflexes across the second tenant
Before testing password writeback we need to add Azure P1 premium licence in both of the tenants
To use password writeback, you must have one of the following licenses assigned on your tenant:
- Azure AD Premium P1
- Azure AD Premium P2
- Enterprise Mobility + Security E3 or A3
- Enterprise Mobility + Security E5 or A5
- Microsoft 365 E3
- Microsoft 365 E5
- Microsoft 365 F1
- Microsoft 365 Business
The following was applied to the tenants
Licence has been applied to users and this is reflected in office 365
Password has been changed on OWA for ‘synced user1’ on tsdemotest1.onmicrosoft.com
Checking if password writeback works then syncs through to syncserver2 and the second tenant can log in using the same password changed in tenant one
After running a delta on syncserver1 the last password was modified, ran the delta sync on syncserver2 afterwards and it showed the same result
Password writeback was successful, the same password the able to used in both tenants
This test proves that we can have one source of identity split to two separate tenants using different source attributes and password writeback works across both tenants regardless where the password is changed. Based on this there should be no reason we can exclude certain attributes from one AAD connect and writeback the information which would cause no conflict with the second.
