Map on premises domain.local to custom domain on azure AD

Question

Our on premises windows domain is not public, it is myDomain.local.
In Azure Active directory we have created a custom public domain publicDomain.com and we have the legacy domain publicDomain.onMicrosoft.com.
We want to sync users from myDomain.local to publicDomain.com but they are created inside publicDomain.onMicrosoft.com.
According to Microsoft support the only way to achieve this goal is to re-install Azure Connect and tell it to use a specific field to create new users in Azure AD. For example we can set user mail field to n.surname@publicDomain.com to create that user principal name in Azure AD.
I found this related post which says to put a DNS entry , but I cannot understand how it may work.
Is there another way to force Azure AD to map users from myDomain.local to my custom domain publicDomain.com ?
Can the synchronization rules editor be used for this scope ?

Update - Request for clarifications

To summarize our system:
-Azure Ad Connect is installed on server 1 and is configured to create azure ad users from the field mail od local AD user.
Here is the relevant part of the configuration:

"identityMappingPolicy": { "azureSourceAnchorAttribute": "mS-DS-ConsistencyGuid", "userPrincipalNameAttribute": "mail", "userMatchingPolicy": "AlwaysProvision" },

AAD Connect Provisioning Agent is installed on server 2 and no configuration was requested, so I suppose it is using the same of Azure Ad Connect on server 1 and stored (?) on Azure AD.

In the Azure AD Connect cloud sync page I can select ** myDomain.local** and at step 2 I can modify the mapping

userPrincipalName rule is the default one:

IIF(IsPresent([userPrincipalName]), [userPrincipalName], IIF(IsPresent([sAMAccountName]), Join("@", [sAMAccountName], %DomainFQDN%), Error("AccountName is not present")))

while I would expect to find the mail field here.

Besides I wonder if I could only change %DomainFQDN% to publicDomain.com in order to map users correctly. Anyway I'm not going to make this test because Azure AD is working fine now and don't want to break it.

Answer 1

Hi @Filippo Martinelli • Thank you for reaching out.

There are 2 ways to achieve this. I would recommend the first option:

1 :- By adding additional UPN suffix i.e., publicDomain.com in your local AD and then flip publicDomain.local UPN suffix with publicDomain.com for all users. You can use below PowerShell script for this purpose:

$LocalUsers = Get-ADUser -Filter "UserPrincipalName -like 'publicDomain.local'" -Properties userPrincipalName -ResultSetSize $null  
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@publicDomain.local","@publicDomain.com"); $_ | Set-ADUser -UserPrincipalName $newUpn}  

Read More: https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization?view=o365-worldwide

2 :- If you already have publicDomain.com suffix in the mail attribute of all on-premises users, you may consider synchronizing mail attribute from Local AD as UPN to Azure AD. With default configuration, On-premises UPN is synced as UPN in Azure AD and the sync rule "In from AD - User Common" is used by default for this purpose. Below is the default syntax of the sync rule for syncing UPN:

IIF(IsPresent([userPrincipalName]),[userPrincipalName], IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))

However, you can clone the default rule and update the rule syntax for UPN as mentioned below:

IIF(IsPresent([mail]),[mail], IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))

This means, if the mail field is present use mail field. If it's not present check if SamAccountName is present. If it is present use SamAccountName with domain field. If SamAccountName is not present either throw an error.

Note: The new rule has to be created with a unique precedence number and the order or the rules is important. Which is why support recommended you to reinstall and select Mail attribute to be synced as UPN. If you decide to go with this option, make sure this change is tested before implementing in production environment.

I think you misinterpret the related post, as the DNS entry is required to verify the custom domain in Azure tenant and not to map users between local AD to Azure AD.

-----------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.