Azure user email attribute won't update after directory sync. Only one user is affected

Question

I am normally able to modify the email attribute for an Active Directory user account and then synchronize that change to Azure via a powershell command. I have one user account that this does not work with. Regardless of what I change the email attriubte to in AD, it continues to show the email as the active directory users UserPrincipalName in Azure.

I've seen issues with Microsoft exchange users that have specific attributes added to their AD user that caused the same problem, but this user has never had an exchange account and those attributes don't exist for the user.

Answer 1

Hi @Donald CrawfordAdmin ,

If you have updated the value on prem but it is still not synchronizing to Azure, the root cause could be related to formatting, licensing, shadow attribute synchronization, the mailNickName setting, or other name configuration issues.

In the on-premises Active Directory, make sure that the proxyAddress attribute is formatted correctly. The SMTP parameter has to be in capital letters to specify the default mail. https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/proxyaddresses-attribute-populate

If it's updated correctly on-prem and you need to force the update in Azure, you can try using:

Set-AzureADUserExtension

If the user is licensed for Office 365 A1 for students, you may want to remove that license. I have seen some rare cases where licensing for certain applications overwrites that attribute.

Another possibility is that Entra is reading from the shadow attribute. Some attributes have two representations in Microsoft Entra ID. Both the on-premises value and a calculated value are stored. These extra attributes are called shadow attributes. The two most common attributes where you see this behavior are userPrincipalName and proxyAddress. The change in attribute values happens when there are values in these attributes representing non-verified domains. But the sync engine in Connect reads the value in the shadow attribute so from its perspective, the attribute has been confirmed by Microsoft Entra ID.

For an unverified domain, the domain suffix will take initialdomain.onmicrosoft.com . The prefix of the Microsoft Online Email Routing Address (MOERA) comes from mailNickName, so you may need to make sure to set the on-prem user's mailnickname is set to the correct name if it is not currently set. One thing to remember, though. Once the MOERA is set, you can't change it. You would remove the existing user, and recreate a new one after the mailnickname in the on-prem AD is properly set. For more reading: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname

If these steps do not work I would recommend creating a support case as it's harder to troubleshoot this without knowing details such as the original attribute, the unmatched attribute, whether you are using a verified domain, and what the Entra logs show.

If the information helped you, please Accept the answer. This will help us as well as others in the community who may be researching similar questions.

Answer 2

Hello @Donald CrawfordAdmin

This issue might be due to a few reasons:

1. GUID Mismatch: If the users were created in Azure prior to the first sync, AD and Azure will see the users as two different accounts since the GUID will be queried rather than the user name. Doing a hard match or soft match on the affected users is one way to fix this.
2. UPN Suffix: If the username for your on-prem AD is user@Companyportal.local or ******@Companyportal.xyz and the verified domain that you have added is contoso.com, you would need to add an additional UPN suffix in your on-prem AD (for example, contoso.com) and flip the UPN of all users from user@Companyportal.local or ******@Companyportal.xyz to user@Companyportal.com.
3. MAIL and PROXY attributes: Check the MAIL and PROXY attributes in AD. In PROXY, make sure the mail email address has all-caps SMTP: and any other email address have lowercase smtp: You can use Powershell to correct this.
4. Primary Domain: For the issue not to occur again, you need to make sure to set the domain you want as your primary domain under Azure Active Directory > Custom Domain names > Make primary.
5. Office 365 Licensing: Licensing for Office365 could be the culprit. When users are assigned licenses (Specifically Office 365 A1 for students), certain applications like Information Barriers and Exchange Online could cause the overwrite of that attribute.

Please try these solutions, and let the community know if it works and fulfils your solution.