This week, I was contacted by an organization who were in the process of starting anew with Active Directory Domain Services (AD DS). The old Active Directory forest was too … old, basically. It showed signs of problems around attribute integrity, schema extension bloat and delegation defaults from the 00’s.

The challenge I assisted with, was a challenge around Azure AD Connect and object matching between the previously synchronized Azure AD tenant and the new Active Directory forest.

Object matching, the other way around

I wrote quite a lengthy blog post on soft-matching and hard-matching between Active Directory user objects and Azure AD objects. This blogpost details how to use the Azure AD module to set the mS-DS-ConsistencyGuid attribute as the ImmutableID  attribute in Azure AD. However, this time, the process is the other way around.

There’s a couple of things you need to be aware of:

Set-AzureADUser –ImmutableId $Null doesn’t work anymore

For some reason, Microsoft botched the ability to clear the ImmutableID for Azure AD user objects. My experience is you can’t achieve this through Set-MsolUser, Set-AzureADUser, Azure AD Graph API or Microsoft Graph API reliably anymore.

Hard-matching before Soft-matching

When the ImmutableID is set for an Azure AD user object, Azure AD Connect will not perform soft-matching for that object. Instead, it expects to perform hard-matching, only. If hard-matching doesn’t work, for instance because the object in Active Directory doesn’t have the mS-DS-ConsistencyGuid attribute filled, soft-matching is not attempted.

Assumptions

Going forward, we acted on the following assumptions (that we double-checked):

1. Objects from the previous Active Directory forest are not synchronized anymore to Azure AD and all objects show as cloud mastered objects in the Azure AD tenant.
2. The objects in the new Active Directory Forest do not have values for their mS-DS-ConsistencyGuid attributes.
3. Azure AD Connect is already deployed in the new Active Directory Forest and only has the users for the new Active Directory Forest in scope.
4. The userPrincipalName attributes for the users in the Active Directory Forest match with the userPrincipalName attributes for the corresponding users in Azure AD.

Action plan

The action plan, therefore, is to fill the mS-DS-ConsistencyGuid attribute of a user object in Active Directory with the ImmutableID of the corresponding user object in Azure AD. Indeed, we need to match the user objects manually.

After we’ve matched the objects, we can set the value using the Set-ADUser Windows PowerShell cmdlet.

Script

To perform the actual changes on the mS-DS-ConsistencyGuid attribute for each user object in Active Directory, we use the following lines of Windows PowerShell:

# Change this value, or feed it from a For-Each loop

$upn = ‘joshaarbos@domain.tld’

# Sign into Azure AD with a privileged user

Connect-AzureAD

 # Do not change anything below

Import-Module AzureAD

function ConvertFrom-ImutableIDToMsConsistencyGuid {

      Param(

          [String]$ImmutableID

     )

     [GUID][System.Convert]::FromBase64String($ImmutableID)

}

$ImmutableID = Get-AzureADUser -UserPrincipalName $upn | Select-Object -ExpandProperty ImmutableId

$MsDsConsistencyGuid = ConvertFrom-ImutableIDToMsConsistencyGuid -ImmutableID $ImmutableID

Set-ADUser –UserPrincipalName $upn -Replace @{'mS-DS-ConsistencyGuid' = [GUID]$MsDsConsistencyGuid}

What happens next…

Since Azure AD Connect does do soft-matching (as the ImmutableID attribute is present for the Azure AD object), Azure AD Connect gets that we perform hard-matching. Now, It will match the user objects in Azure AD to the corresponding user object in the new Active Directory forest.

As we took care of all the necessary passwords, group memberships, etc., we can resume business as usual.

Concluding

The above approach can be used to match previously synchronized user objects to new user objects from a new Active Directory Forest.

Of course, A better way is to use ADMT and include the mS-DS-ConsistencyGuid attribute in scope for migration and both Active Directory Forests in scope for the same Azure AD Connect installation. This minimizes the duration of the project, migrates all memberships and passwords (using PES) for you and makes it a much easier experience.

But … Some projects don’t start at the logical starting point.