With Azure AD Connect it’s easy to sync users from the Active Directory to the Azure AD, but it’s not possible to sync users from the Azure AD to the Active Directory. In this blogpost I will show how you can export an account and how to resolve some common issues.
How are users synced
First we need to know how a sync of a new account works. This can be found on this Microsoft page, here we can find the following information:
the Azure AD sync service (in Azure AD) does a check on every new object and try to find an existing object to match. There are three attributes used for this process:
– userPrincipalName
– proxyAddresses
– sourceAnchor/immutableID.
A match on userPrincipalName and proxyAddresses is known as a soft match. A match on sourceAnchor is known as hard match. For the proxyAddresses attribute only the value with SMTP:, that is the primary email address, is used for the evaluation.
two kinds of matches:
– Soft Match – based on UPN and proxyAddresses
– Hard Match – based on sourceAnchor/immutableID
What happens when an Account Matches
If Azure AD finds an object where the attribute values are the same for an object coming from Connect and that it is already present in Azure AD, then the object in Azure AD is taken over by Connect. The previously cloud-managed object is flagged as on-premises managed. All attributes in Azure AD with a value in on-premises AD are overwritten with the on-premises value. The exception is when an attribute has a NULL value on-premises. In this case, the value in Azure AD remains, but you can still only change it on-premises to something else.
– When an account in the Active Directory matches the Account in Azure AD will change from Source “Azure Active Directory” to “Windows Server AD”.
– The attributes in the Azure AD will be overwritten with the attributes from the Active Directory
Important:
Make sure the attributes in the Active Directory are Up-To-Date before you sync. The accounts will be managed from the Active Directory after the sync.
New Azure AD account
Now we now how te matching works let’s have a look at the attributes of an account created in the Azure AD. I’ve created an account with the UPN azureuser@vmlabblog.com to demonstrate. To show the attributes I will connect to Azure with Powershell using the MSOnline module.
First I will connect to Azure using the following command:
Connect-MsolService
To request the attributes from the user I will use the following command:
Get-MsolUser | Where-Object {$_.UserPrincipalName -eq "azureuser@vmlabblog.com"} | Select-Object UserprincipalName,proxyAddresses,ImmutableID
In the result we see that an Azure AD account which has been created in the Azure AD only has the UserPrincipalName attribute.
When you create an Active Directory account only the UPN will be used to (Soft) match the account with the Azure AD account.
Sync Ad account with Azure AD
The Azure AD account I’ve created has the following properties and also has the source “Azure Active Directory because it has been created in the Azure Portal:
Now I will create a new Active Directory account using the same UPN but with my name.
When I perform a delta sync and refresh the Azure Ad account, you can see that names of the Azure account have changed, but the user name and Object ID are still the same. Also the Source of the account has changed to Windows Server AD.
When we now take a look at the attributes of the account we will see that the attribute “ImmutableId” has been added tot the account:
Now the account has an ImmutableId it will no longer be possible to soft match the account.
Export an Azure AD account to the Active Directory using Powershell
First export the AzureAD user to a CSV file
$UPN = "azureuser@vmlabblog.com"
$CSV = "C:\Temp\Azure-User-Export.csv"
Get-MsolUser | Where-Object {$_.UserPrincipalName -eq $UPN} | Select-Object City, Country, Department, DisplayName, Fax, FirstName, LastName, MobilePhone, Office, PasswordNeverExpires, PhoneNumber, PostalCode, SignInName, State, StreetAddress, Title, UserPrincipalName | Export-Csv $CSV -Encoding UTF8
Next step is to import the user in your domain.
$CSV = "C:\Temp\Azure-User-Export.csv"
$PWD = "Topsecret!"
import-csv $CSV -Encoding UTF8 | foreach-object {New-ADUser -Name ($_.Firstname + "." + $_.Lastname) -SamAccountName ($_.Firstname + "." + $_.Lastname) -GivenName $_.FirstName -Surname $_.LastName -City $_.City -Department $_.Department -DisplayName $_.DisplayName -Fax $_.Fax -MobilePhone $_.MobilePhone -Office $_.Office -PasswordNeverExpires ($_.PasswordNeverExpires -eq "True") -OfficePhone $_.PhoneNumber -PostalCode $_.PostalCode -EmailAddress $_.SignInName -State $_.State -StreetAddress $_.StreetAddress -Title $_.Title -UserPrincipalName $_.UserPrincipalName -AccountPassword (ConvertTo-SecureString -string $PWD -AsPlainText -force) -enabled $true }
Move the user to the container which is synced to the Azure AD
Matching issues
Recreated Account
Matching issues occur when the user is recreated between two sync intervals. Each time a user is created it will get a different ImmutableID as you can see in the screenshot:
If an account has an ImmutableId it will only be possible to perform changes when the ImmutableId has a hard match otherwise a new account will be created with as you can see in this screenshot. The account will be named “UsernameXXXX@<companyname>.onmicrosoft.com”:
Workaround
To prevent this from happening, the ImmutableID needs to match the new ImmutableID before syncing. This can be done by the following command which will retrieve the ImmutableID from the AD and will set this in the Azure AD:
$UPN = "azureuser@vmlabblog.com" $Guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$UPN)").objectGuid) $ImmutableId = [System.Convert]::ToBase64String($guid.ToByteArray()) Set-MsolUser -userprincipalname $UPN -ImmutableID $ImmutableId
Roles not matching
When you try to sync an Active Directory account to an Azure AD account with an assigned admin role the account will not be matched and the same situation will occur as with a not matching ImmutableId. This is to prevent untrusted on-premises users from matching with a cloud user that has any admin role.
Workaround:
Microsoft advises the following steps to resolve these issues:
1. Remove the directory roles from the cloud-only user object.
2. If there was a failed user sync attempt, hard delete the Quarantined object in the cloud.
3. Trigger a sync.
4. Optionally add the directory roles back to the user object in cloud once the matching has occurred.
Hi Add,
First thank you for taking the time for writing this article for us coming up the Azure learning curve.
1. So in summary, for existing AAD cloud only accounts e.g exchange online account, it seems soft match is your only real option to sync those users with their local AD? E.G Using Exchange Online, Upgrade to new Server 2019 and decide to go hybrid. That’s Us!
2. Hard match is for customers who create a new AD with new / existing users, then run AD Connect and create those accounts in their shiny new tenant?
3. Once an account has been soft matched, can azure switch too hard match for those soft matched accounts, hence populating the immutableID? After all, Azure has verified the accounts match.
What concerns me is this statement from MicroSoft,
” SMTP matching can be used only one time for user accounts that were originally authored by using Office 365 management tools. After that, the Office 365 user account is bound to the on-premises user by an immutable identity value instead of a primary SMTP address.” Sort of implies point 3 above?
I am not sure what that means, I could interpret that a few ways? What are the implications of this statement? My server dies and I replace the Server? What happens then.
Thanks,
Stewart
Hi Stewart,
A hard match will only be done if the immutableID already exists in the Azure AD. The immutableID will be added to a cloud account when a soft match has been performed. This happens during a Azure AD synchronization with Azure AD Connect. Once the immutableID has been added to the account it will no longer be cloud managed, but it needs to be managed by the on-premises Active.
to answer your questions:
1. Soft match only applies to cloud accounts which have been created in the Azure AD. The account does not exist in the Active Directory. after you create the account with the same UPN it will be soft matched and the account will no longer be Azure AD managed, but managed with the Active Directory. If you want to make changes to the account you need to make the changes in the Active Directory and sync it to the Azure AD.
2. After a soft match the ImmutableID will be added to the account. When the ImmutableID exists only a hard match will be performed based on this ImmutableID. As long as the account contains a ImmutableID a soft match will not be possible.
3. Yes, see above (2).
If you’re server dies you can do two things:
1. Disable Azure AD sync by executing Set-MsolDirSyncEnabled –EnableDirSync $false. This will convert the accounts in the Azure AD to cloud managed.
2. Use a backup or export the Azure AD accounts to the on-premises Active Directory. Now you need to match the accounts ImmutableID as I described in Matching Issues.
best regards,
Aad Lutgert
Brilliant article, I am hoping to use it to help “reverse” sync our AD.
is there a way to export all attribute for users, that way we can import it into On-Prem AD and they be up-to-date? Just in case any issue appear if attributes are accidently changed in On-Prem AD and then Sync across.
Assuming that all NULL on prem still appear NULL in on prem. but stay as set in AZAD?
Just to add as well.
What about when the On-Prem Domain named differently compared to the AzureAD?
Hi Aad,
Thank you for the brilliant artical, I am happen to utiles it.
We are planning to run a project of migirating Azure AD Users,Groups and Device to Local Active Directory.
My questions is
When we
A-export Azure users,match usernames and UserPrincipalnames
B-Import to on-premise AD
C-Finaly Use AAD Connect to sync objects to Azure AD
Will this affect the existed mailboxes on Exchange online which belongs to exported, imported and finaly sync users?
Please advise.
Best regards
Naadi
Hi Aad,
Thank you for this artical, I am happen to utiles it.
We are planning to run a project of migirating Azure AD Users,Groups and Device to Local Active Directory.
My questions is
When we
A-export Azure users,match usernames and UserPrincipalnames
B-Import to on-premise AD
C-Finaly Use AAD Connect to sync objects to Azure AD
Will this affect the existed mailboxes on Exchange online which belongs to exported, imported and finaly sync users?
Please advise.
Best regards
Naadi
Hi Naadi,
This shouldn’t be a problem. The Azure AD accounts will be associated with the AD accounts. There will be no changes to the account, only to the ImmutableID.
regards, Aad
Hi Aad,
Can I ask a question about this line : – ‘The attributes in the Azure AD will be overwritten with the attributes from the Active Directory’
When you say attributes do you just mean the userPrincipalName, proxyAddresses and sourceAnchor/immutableID? Or will Connect wipe out details such a Job Title, Telephone number etc.?
Thanks
Josh
Hi Josh
The UPN wil be used to soft match, the other fields in the Azure AD with a value will be overwritten with the values from the fields in on-premises AD. Except for fields with a NULL value. So to answer your question: the proxyAddresses, sourceAnchor/immutableID but also Job Title, Telephone number etc. if these fields have a value other than NULL.
regards, Aad
Hello, thank you for the fantastic article that Iam going to use to sync our Azure AD users to a new built on prem Domain Controller.
Our main target is to allow our cloud users to authenticate to Wifi using their AAD credentials through local NPS server.
However, my concern is:
What happens to the password of the current Azure AD user? Is there a way I can sync the password without knowing the password of user ?
As I have read, sync is only in one direction which is from AD to cloud and we are importing existing AAD users to new local on prem AD. So what is the best option regarding the password sync here.?
Will I have to reset the password for all users?
Hi,
As far as I know it’s not possible to do this without resetting the passwords of all users. As you point out, password sync only works one way: from AD to Entra ID. An exception is password writeback, but in that scenario the password has already been synced once.
regards, Aad