samAcocuntName issue in Azure AD Domain services

[JasjitChopra]

I have a weird issue with user object synchronization where samAccountName differs in AAD Domain Services.

On Prem AD User: UPN: firstName@domain.com samAccountName:firstName

AAD Domain Servcies User: UPN: firstName@domain.com samAccountName: firstNamelastName

So when I login I cannot use domain\firstName to login I have to either user firstName@domain.com or Domain\firstNamelastName to login.

How did this samAccountName in the AAD Domain Services change? And why are the delta/full sync not picking up this change in the AAD Domain Services?

[#2]

Hello @JasjitChopra, did you make any progress investigating why account name changed?

[#3]

Sorry for the late reply - but i am afraid I was not able to resolve this. I simply had to reset the whole setup and now everything is working as expected.

[#4]

I`m glad you made it work afterall. @Adam Fowler, have you seen this before? If Jasjit sees it again, is the reset the only option?

[#5 · Accepted solution]

This should just come down to the Azure Active Directory Connect options you have (assuming you're using that and not ADFS). First image on this article: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-user-sig... shows the option on 'select the on-premises attribute to use as the Azure AD username' which may have just had 'firstname' selected.

Azure AD Domain Services just gets given what it's given 🙂

Guessing Jasjit deleted accounts/Azure AD and started again, otherwise you'd have to change them manually with PowerShell https://www.adamfowlerit.com/2016/05/wrong-domain-users-azure-active-directory/ 

[#6]

I have seen  this issue in another way, For instance i had a similar issue with password sync when we setup a new Azure AD sync from another server with another account. We did not clean up the old sync good enough so when we turned on the new Azure AD sync the old account was used and the old domain was syncing over the new Connectors from our new server in our new domain. So apparently microsoft keeps some sort of backup of you setting in there environment so you can get a Azure AD sync up and running really quick after disaster recovery.

You can check these kind of settings when you load in the msol service with powershell and run the get-msolcompanyinformation Command.

Maybe this is something like the same as you are experiencing.

[#7]

Thanks @Daniel Martins @Jerry Meyer @Adam Fowler

The issue indeed had nothing to do with Azure AD Domain Services it was the way the object was synced to the Azure AD in the first place due to a duplicate item created long back. Before I could troubleshoot this in detail I had to move my office 365 tenancy to another tenant as it was created in wrong country ages ago by mistake.

Apologies for the late reply but everything you guys are pointing out makes sense and I definitely have a better and clear understanding of troubleshooting and approching this issue in a better and faster way in future 🙂