UPN Mismatch between Local AD and Azure AD (Entra ID) impact on user sign-ins and SSO?

[Curious_Kevin16]

Hello Smart people,

I have a Active Directory domain to be synced with Entra ID. This Entra ID tenancy though, is already exists and users are created. 

There are two different UPNs in current environments.

Local AD - user1@company.com.nz

Azure AD - user1@company.com

Local AD doesn't have any Suffixes configured. email address removed for privacy reasons is the email address of Local AD account properties where as UPN is email address removed for privacy reasons. So there's a mismatch of the two UPNs.

My question is, as this issue will have a major impact on user sign-in/SSO due to this mismatch, what's the best way to overcome this ?

Do I have to add the suffix company.com in AD and change on-prem user UPNs with that suffix and then sync? Is there any better ways to deal with this?

Any ideas/inputs are greatly appreciated.

Thank you!
Kev

[#2]

Hi Curious_Kevin16,

If you need to make configuration changes, then you want to disable the Microsoft Entra Connect Sync scheduler.

Microsoft Entra Connect Sync configuration best practices:

- Use the ms-DS-ConsistencyGuid (or objectGUID) as the sourceAnchor attribute for User objects. The sourceAnchor attribute uniquely identifies an object as being the same object on-premises and in Microsoft Entra ID

- Use "Password hash synchronization"

- Sync only specific OUs

- Don't sync service or admin accounts

Active Directory:

- Add the alternatieve UPN suffix to your Active Directory Domains and Trusts

- Use the routable domain as User logon name in Active Directory Users and Computers. Also check the mail- (and proxyAddresses) attributes

Enable the scheduler again.

Important: the on-premises sourceAnchor ms-DS-ConsistencyGuid (or objectGUID) should always match the ImmutableID in Microsoft Entra ID.

[#3]

@MathieuVandenHautte Thanks for your swift response ! 

I haven't configured the sync schedules yet. Connector is yet to be setup hence the questions before touching that space. 

My concerns are more towards the impact of UPN change. as these users leverage @company.com.nz (not @company.com) to login to their local devices and applications, what implications will this UPN change have on them? and the best workaround to address it. 

Thanks again

Kev

[#4]

@Curious_Kevin16 

Hi, Kev.

There's multiple pathways for dealing with this kind of scenario depending on the outcome you're trying to achieve.

Some quick questions though:

• Do you currently host mail on-premise, and if so, do people's e-mail addresses also use a suffix of company.com.nz?
• Which authentication model are you looking to use in your final state?
• In the final state, will your clients be hybrid joined or Azure-native?

Authentication methods

• Authentication for Microsoft Entra hybrid identity solutions | Microsoft Learn

Cheers,

Lain

[#5]

Spoiler

Hi Kev,

Users will still be able to login.

The SAM account name (domain\user) does not change when you update the UPN.

I’ve done this on many environments and never had an issue.