Sync existing office 365 tenant with local active directory

Posted On May 2, 2019

Recently we created an AAD tenant that has no on-premises AD domain counterpart.
Now we are facing an issue where we want to be able to use the identities in this tenant to log into some servers. It would appear that we would need to domain join these servers, but we can’t do this without AD. The question is, how can we continue to setup these servers?

If the servers are hosted on the Azure IaaS platform you can choose to go ahead with Azure AD Domain services as I wrote before:
https://www.2azure.nl/2019/04/22/azure-ad-domain-services-an-option-or-not/

But today we are going to install a new domain on-premise. The domain name isn’t relevant for the sync with Azure AD / Office 365. But the UPN for the end users is important! So first we can add the UPN domains by going to the Domain and Trusts console. Add the required domain names.

After the domain names have been setup we can continue with setting up AD Connect on a server within the domain. Download:
https://www.microsoft.com/en-us/download/details.aspx?id=47594

I will create a manual later on with the full AD Connect setup process.

Once the configuration is complete, and the users with the same UPN/email address have been created in both the on-premise AD and Azure AD/Office 365, there are several possible things that can happen when you start the initial sync:

1. If a match is not found based on immutableID, but a user with a matching UPN/email address and a blank immutableId is found, the user will have its immutableId stamped with the new value (determined above) and the AD+AAD users become tied together. This is called a soft match.
2. If a match is not found based on immutableId, but a user with a matching UPN/email address is found but with a different immutableId, a sync error is thrown. AAD Connect will not override the user’s UPN, as they’re not the same object
3. If a match is found based on immutableId, but the object types are different (e.g. AD user matching an AAD Connect contact), AAD Connect will throw an error and refuse to synchronize the objects. This won’t happen in the wild unless someone unintentionally (or intentionally) breaks something

Most of the times you will get a soft match. But what if there is a problem? Usually this is caused by a problem with the immutable ID. (This can be reviewed in the AD Connect logs). There are 2 possible options to solve this problem

Calculate and set immutable ID (Recommended)

This method is the best way to make sure that AD Connect gets a proper sync. We are going to connect to the on-premise AD, and calculate and set the immutable ID in Azure AD / Office 365. So first we connect to Active Directory.

Import-Module Active Directory

Now, lets grab the GUID of the user and create the ImmutableId

$userUPN = "testuser@2azure.nl" 
$guid = [guid]((Get-ADUser -LdapFilter "(userPrincipalName=$userUPN)").objectGuid) 
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())

The last command will be used to write the ImmutableId to the AAD / Office 365 user:

Get-MsolUser -UserPrincipalName $userUPN | Set-MsolUser -ImmutableId $immutableId

Clear immutable ID in Office 365 (Not advised)

The easy way is to clear the immutable ID in Azure AD/ Office 365. This will let AD Connect think that the account has never been synchronized and will sync it based on a soft match. However I wouldn’t recommend it. But if you ever need to do it, here is the commands to do it.

Clear ImmutableId for only 1 user:

Get-MsolUser -UserPrincipalName testuser@2azure.nl | Set-MsolUser -ImmutableId $null

Clear ImmutableId for all users:

Get-MsolUser -All | Set-MsolUser -ImmutableId $null 

New steps sinds 2024:

• Install the Microsoft Graph module if you haven’t already.

Install-Module Microsoft.Graph

• Connect to Entra ID using the Module and consent to permission

Connect-MgGraph -Scopes "User.ReadWrite.All" , "Domain.ReadWrite.All", "Directory.AccessAsUser.All"

• View the user’s current ImmutbaleID value.

Get-MgUser -UserId <user>@example.com -Property OnPremisesImmutableId,UserPrincipalName,Id | Format-List UserPrincipalName,OnPremisesImmutableId,ID

• Null the immutableID of the user

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/Users/<user>@example.com" -Body @{OnPremisesImmutableId = $null}

• View the ImmutableID again, it should be cleared now.
• Run a delta sync to clear the sync error. 

Start-ADSyncSyncCycle -PolicyType Delta

Bonus: It takes some time in the Microsoft Entra Connect Health sync for the errors to vanish. You can check in the “Synchronization Service Manager”, which is installed where also the Azure AD Connect program is installed. There it is immediately displayed. Also this is the place where you can find which user is affected. See the guide for the walk through.