Here I ran into an issue where soft matching existing Azure AD accounts with on-premises AD accounts would not match if they were a global admin. Here is my write-up on this finding
Many organisations have dipped their proverbial toes in Azure with Office 365, while having accounts not linked to Active Directory for password synchronisation. This is steadily changing as companies embrace the cloud, even more so with recent worldwide events.
Usually, the installation of AD Connect on an on-premises server is a regular run of the mill task, sometimes though there are trips and bumps along the path.
One such trip happened recently. A customer had Office 365 installed and tested and was moving to the next phase of Office 365 integration thus needing AD Connect installing. Simple?
The install went fine having selected the required OU(s) and accounts come across, except, even though the userPrincipalName was correct some accounts duplicated with the {username}0000@{domain}.onmicrosoft.com accounts – not what I expected as they were not matching what was there in Azure already.
Get rid of the duplicates 🛑
The first step was to change the OU being synchronised, and I was expecting this to remove the items from Azure AD. This didn’t go as planned, and these particular duplicate accounts didn’t delete.
After some time, and lots of testing it was suggested maybe the Admin role had some bearing, now I wasn’t expecting this to be a factor, and initially discounted that, looking at other possible reasons for the sync not matching.
Useful Lab Environment 💻
Lab to the rescue! Like many IT-centric people, I have a small lab where I can test things without fear of breaking any production systems, so I tried the Admin hypothesis. Created an Admin account in Azure AD, matched it in AD and synchronised them, and got the duplicate.
But in the Lab, I could switch OU, and the accounts would be deleted, then able to clear the recycle bin and continue, on the particular site I was working on this didn’t happen, despite changing the container, the duplicate accounts wouldn’t budge.
So investigating this and again thanks to the Lab, I removed the duplicate accounts through PowerShell, now it goes without saying care needs to be taken when doing these operations, as you are only a few clicks or commands away from disaster.
The Answer, is in PowerShell ⚡
Using PowerShell, linked to Azure AD and with MSOnline modules loaded, I could delete the Objects from Azure AD, empty the recycle bin of those users (if you don’t do this bit sync won’t work for the particular user). I Removed the user from Global Admin (and any other admin roles) in Azure temporarily, then ensured AD Connect was pointing at the correct container and synchronised, this time they matched without a problem.
Commands for those interested:
Install-module -Name AzureAD
Connect-AzureAD
Copy
You will be prompted for credentials, if using older browsers on servers, you may find you need to add the sites, and then the prompt window may fail, just re-run the command, and it should load the credentials request.
Install-module MSOnline
Connect-MSOLService
Copy
A few of the common commands used in this operation:
Get-MSOLUser -UnlicensedUsersOnly
Get-MSOLUser -ReturnDeletedUsers
Remove-MSOLUser -UserPrincipalName "upn-to-remove"
Remove-MSOLUser -UserPrincipalName "upn-deleted-already" -RemoveFromRecycleBin
Copy
Note that after adding back the admin role, in some circumstances the browser cache may need emptying for admin function to work in the Office 365 portal. But at this point, you will have a healthy, synchronised environment!