Reputation: 11
We have a small office, 9 users. From the start everything has been setup in Office 365 and Azure, email, SharePoint, storage, file shares etc and it works great. However, we need local storage for large file technical work. I setup a simple fileserver running Windows Server 2019 within a local network, after reading that trying to manage access with local users was not the best approach I setup Active Directory sync to connect our existing Office 365 users to the servers active directory.
This didn't work well at all, half of the users synced ok the other half didn't. Further having to rely on Active Directory just doesn't seem to add any value for our situation so the sync has now been disabled but some of the office 365 users still recognise themselves as connected to the active directory and not directly to Azure AD as before.
For example in control panel/user accounts on a users machine it should show AzureAD\username but instead it shows the active directory server\username.
Is there a way I can remove all association with the server Active Directory from the user and restore it to AzureAD?
The only way I see now is to have to delete the user account and start again.
Upvotes: 0
Views: 1150
Reputation: 7728
This a known gap. Even though you have migrated the user from your on-premises Active Directory to Azure AD, the on-prem SamAccountName is still intact on the user object, among other on-prem AD attributes. So Azure AD picks those details and shows domain/user instead of AzureAD/user. This attribute cannot be modified or cleared through Graph APIs at this point, so there's no way to change the behavior. That said, it would be worthwhile to create a feature request for this in the Ideas forum. https://feedback.azure.com/
Since you have a relatively small list of users, one option would be to export a list of the users and any other attributes into a csv. From here delete the users that are having the issue. Then import the csv back into your Azure Active Directory.
Another option would be to create a support case to help resolve the issue.
During the account synchronization, Azure AD looks at the UPN and if it is populated, it will use it to create the matching user account in Azure. If the UPN does not match a verified domain, it will be replaced with the default @tenant.onmicrosoft.com value. If the UPN is empty, the SamAccountName attribute will be used instead, with the default domain.
Upvotes: 0