How to export an Azure AD account to the Active Directory

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.

Written By

Aad Lutgert

Leave a Reply

Your email address will not be published. Required fields are marked *