Scenario:
2015: Company had an on-premises AD. Wanted to start using Office365 licenses.
Enabled dirsync/aad connect to synchronize users to AzureAD and use SSO functionality
2017: The company decided to migrate all their on-premises stuff like files, skype to teams and so on. Then dirsync was shut down and all users was considered as “cloud only”.
2020: The company then acquired another company requiring a resource forest AADDS to fulfil migration needs of that specific legacy application portfolio.
Only users from the new onpremise AD and newly created "native" AzureAD accounts are able to consume the resources from the AADDS domain. Previously synced users are excluded from AADDS.
Why?
This is behavior seems to be caused by a hard coded limitation in the AADDS sync engine related to the value for the AzureAD attribute onPremisesSyncEnabled. Sync engine only allows syncronization of users with the value "null", that only native AzureAD users get. Previously synced users gets a value false and are excluded from the sync and denied access to the AADDS resources.
This must be a bug? I can't find any reason for differentiating between previously synced users and native AzureAD users in this context.
onPremisesSyncEnabled is a read only attribute in AzureAD so company has 2 identified options:
1: Recreate all previously synced users, connect email, teams, onedrive and so on. Reinstall PCs to get onPremisesSyncEnabled set to null
2: Delete existing AADDS domain as a user forest and recreate production environment
Anyone having an idea to solve this issue? To me it seems like a bug in the sync engine, meaning they forgot to include the value false as a "valid" value.
