In Hybrid Identity implementations, where objects and their attributes are synchronized between on-premises Active Directory environments and Azure AD tenants, integrity is key; When user objects on both sides have different attributes, or exist multiple times at one side, information security drops to critical levels fast.

To avoid this situation, Azure AD Connect matches user objects from the on-premises Active Directory to Azure AD.

Upon provisioning an object from on-premises Active Directory to Azure AD, Azure AD performs additional actions one time, when compared to updating a user object. These two action are named:

1. Hard Matching
2. Soft Matching

The actions are performed in the above sequence; Hard matching is attempted, before soft matching is attempted. If there’s no match, a new user object is created in Azure AD to correspond to the user object in the on-premises Active Directory environment.

Hard Matching

To definitively match an on-premises Active Directory user object to an Azure AD user object, Azure AD Connect looks at the sourceanchor attribute.

During normal synchronization cycles, this attribute is already used to provide the end-to-end connection between the on-premises Active Directory user object and the Azure AD user object through Azure AD Connect’s connector spaces and metaverse, so it’s an ideal way to match.

The Azure Active Directory Connect wizard, used to configure Azure AD Connect installations provides options to choose the sourceanchor attribute:

The above screenshot is a screenshot of a recent versions of Azure AD Connect. It provides the default option to Let Azure AD manage the source anchor and a list of available attributes to use as an alternative through the Choose a specific attribute option.

Let Azure AD manage the source anchor

When the Let Azure AD manage the source anchor option is selected, Azure AD Connect checks if there is a previous (older) Azure AD Connect installation connected to the Azure AD tenant. If there is, it will default to the objectGUID attribute . If this is the first Azure AD Connect installations, or all other Azure AD Connect installations have already been migrated to use mS-DS-ConsistencyGUID as the sourceanchor attribute for user objects, the mS-DS-ConsistencyGUID attribute is automatically selected as the sourceanchor attribute.

Choose a specific attribute

When you Choose a specific attribute it is important to choose an attribute that:

1. Does not exceed 60 characters in length
2. Does not contain special characters like \ ! # $ % & * + / = ?  and ^
3. Is globally unique throughout your organization
4. Is either a string, integer or binary

A good sourceanchor attribute is not based on a person’s name, because this may change, however some organizations still choose to do so, based on the mail attribute…

Note:
The sourceanchor attribute chosen is stored in the configuration of the Azure AD tenant.

Note:
When upgrading or changing settings, Azure AD Connect reports that the Azure AD Connect installation for this tenant still uses objectGUID to synchronize user objects.

Hard matching occurs, based on the following data:

An example for writing the immutableID attribute to an Azure AD object, based on an Active Directory user’s objectGUID attribute using Windows PowerShell is:

$user = jos.haarbos@domain.tld

$guid = [guid]((Get-ADUser -Identity $user)“).objectGuid)

$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())

Connect-AzureAD

Set-AzureADUser -UserPrincipalName $user -ImmutableId $immutableID

When hard matching provides a match, soft matching is not attempted. However, the non-matching rules still apply.

Soft Matching

When hard matching doesn’t provide a match, soft matching is attempted. Soft matching is little more straight-forward than hard matching as it’s based on the following data:

Through soft matching, anon-premises Active Directory user object is matched to an Azure AD user object, when:

1. The userPrincipalName attributes match
2. The userPrincipalName attribute for the on-premises user object matches with any of the e-mail addresses in the Azure AD user object’s proxyAddresses attribute
3. The primary SMTP address (denoted with SMTP: in the proxyAddresses attribute matches the userPrincipalName or any of the e-mail addresses in the Azure AD user object’s proxyAddresses attribute

When soft matching provides a match, hard matching is established at the first synchronization cycle by setting the immutableID attribute for the Azure AD user object, based on the sourceanchor configuration. This is done for disaster recovery purposes: When the (only) Azure AD Connect installation fails, a replacement Azure AD Connect installation can pick up synchronization for end users by accurate hard matching.

Non-matching

To avoid information security-related incidents, like the one pointed out by Dirk-Jan Mollema at Troopers 19, Azure AD Connect no longer attempts to hard match or soft match Active Directory user accounts to Azure AD-based user objects with privileged roles, like the Global Administrator role.

Caveats

Now, the above explanation is straight-forward. There are a couple of caveats, though, that you should take into account:

1. When you delete an object in Azure AD and then synchronize an object from on-premises to Azure AD within 30 days, hard matching and soft matching may not be triggered. Instead the previously deleted object is matched and reanimated. This is because the object was deleted, but not purged from the Azure AD Recycle Bin. Perform the following steps to get the result you want: Delete the object, purge the object, perform a sync cycle.
2. In environments without existing Exchange Online-deployments, when you really don’t want an object in Azure AD to be matched with an on-premises AD object, assign the Azure AD object the tenant-specific userPrincipalName suffix (@*.onmicrosoft.com) and clear the immutableID attribute.
3. When the Azure AD Connect installation fails and a replacement Azure AD Connect installation takes over, synchronized user objects in Active Directory matched to Azure AD privileged roles will not be matched. For this scenario:
   1. Make sure at least one non-synchronized Global Admin account exists with the @*.onmicrosoft.com userPrincipalName suffix
   2. Make sure you have Password Hash Synchronization (PHS) deployed

Concluding

Hard matching is useful in both on-premises and cloud migration scenarios and to pinpoint a specific on-premises user object to an Azure AD object.

When things are slightly less difficult, soft matching provides the right amount of flexibility and speed to finish an Azure AD Connect implementation as part of a Hybrid Identity project within the allotted time.

Just remember you can’t synchronize admins anymore…

Further reading

Azure AD Connect: When you have an existent tenant
Soft (SMTP) vs. Hard (immutableID) matching with Azure AD Connect
How to use SMTP matching to match on-premises accounts to Office 365 accounts
Azure AD Connect soft- vs. hard matching explained

Recent versions of Azure AD Connect deploy a Service Connection Point (SCP) into your Active Directory Domain Services (AD DS) environment(s). Let’s look a bit closer to what this SCP looks like, what it does by default and how you can use and tweak it to your advantage.

About Service Connection Points

Active Directory allows for a specific object that points to specific services. This way, an application, system and/or service administrator can provide guidance on where to find the (nearest) instance of his/her application, system and/or service to domain-joined devices and LDAP-enabled devices.

Many Microsoft and 3rd party applications and services have embraced the concept of service connection points in Active Directory in the past. Microsoft Exchange, Microsoft System Center Configuration Manager (SCCM) and Active Directory Rights Management Services are the ones that come to mind.

About Azure AD Connect’s SCPs

Azure AD Connect’s Service Connection Point includes information on the following items in its Keywords attribute:

1. azureADId; The Azure Active Directory tenant ID
2. azureADName; The Azure Active Directory tenant’s verified custom DNS domain name, or the *.onmicrosoft.com DNS domain name if no verified custom DNS domain name exists for the Azure AD tenant

Azure AD Connect’s Service Connection Point exists as:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=domain,DC=tld

The Service Connection Point needs to be available to all domains in the Active Directory forest that contains computer objects.

When is the Service Connection Point created?

Azure AD Connect creates the Service Connection Point in Active Directory, when:

1. You install and configure Azure AD Connect with Express Settings, or;
2. You install and configure Azure AD Connect. Then, you enable Hybrid Azure AD Join while supplying Enterprise Admin credentials, or
3. You install and configure Azure AD Connect. Then, you enable Hybrid Azure AD Join, and use the ConfigureSCP.ps1 script to create the Service Connection Point manually.

Inspecting the keywords

You can easily get the information in the Keywords attribute using the following lines of Windows PowerShell:

$scp = New-Object System.DirectoryServices.DirectoryEntry

$scp.Path = “LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,`
CN=Device Registration Configuration,CN=Services,CN=Configuration,`
DC=domain,DC=tld“

$scp.Keywords

When is the information used?

The information in the Service Connection Point is used by domain-joined devices during their Hybrid Azure AD Join to discover Azure AD tenant information through an LDAP query. The device performs Home Realm Discovery (HRD) based on the azureADName keyword.

Situations with multiple Azure AD tenants

Microsoft’s vision scope for Hybrid Azure AD Join and Device WriteBack is one Active Directory forest connected to one Azure AD tenant. However, for complex organizations, this is not feasible. For these organizations, an alternative to the Service Connection Point point to one Azure AD tenant is available as client-side registry settings.

Clear the Service Connection Point

To use this method, clear Azure AD Connect’s Service Connection Point object first:

1. Launch ADSI Edit (adsiedit.msc) with an account that is a member of the Enterprise Admins group in Active Directory.
2. Connect to the Configuration Naming Context of your domain.
3. Browse to CN=Configuration,DC=domain,DC=tld, then CN=Services and finally CN=Device Registration Configuration.
4. Right click CN=62a0ff2e-97b9-4513-943f-0d221bd30080 and select Properties from the context menu.
   1. Select Keywords from the Attribute Editor window and click Edit.
   2. Select the values of azureADId and azureADName (one at a time) and click Remove.
5. Repeat steps 2-4 for each domain in the Active Directory forest.
6. Close ADSI Edit.

Create client-side registry settings

Use the following example to create a Group Policy Object (GPO) to deploy a registry setting configuring a Service Connection Point entry in the registry of devices in scope:

1. Open the Group Policy Management console (gpmc.msc)
2. Create a new Group Policy Object where you want to Service Connection Point information to propagate to.
3. Edit the Group Policy Object.
4. Navigate to  Computer Configuration > Preferences > Windows Settings > Registry.
5. Right-click on the Registry node and select New > Registry Item.
6. On the General tab, configure the following:
   1. Action: Update
   2. Hive: HKEY_LOCAL_MACHINE
   3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
   4. Value name: TenantId
   5. Value type: REG_SZ
   6. Value data: The GUID or Directory ID of your Azure AD instance (This value can be found in the Azure portal > Azure Active Directory > Properties > Directory ID)
7. Click OK to save the Registry item.
8. Right-click on the Registry and select New > Registry Item again.
9. On the General tab, configure the following
10. 1. Action: Update
    2. Hive: HKEY_LOCAL_MACHINE
    3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
    4. Value name: TenantName
    5. Value type: REG_SZ
    6. Value data: Your verified domain name if you are using federated environment such as AD FS. Your verified domain name or your onmicrosoft.com domain name for example, contoso.onmicrosoft.com if you are using managed environment
11. Click OK to save the Registry item.
12. Close the Group Policy editor window.
13. Link the newly created group policy object to the desired Organizational Unit (OU) containing domain-joined computers.
14. Close the Group Policy Management console.

How the information can be abused

The information in the Service Connection Point can be abused. The Network Service Scanning technique in the MITRE ATT&CK framework (T1046) specifically hints at the way the information can be abused:

With cloud environment, adversaries may attempt to discover services running on other cloud hosts or cloud services enabled within the environment. Additionally, if the cloud environment is connection to an on-premises environment, adversaries may be able to identity services running on non-cloud systems.

Concluding

Azure AD Connect’s Service Connection Point allows for domain-joined devices to perform Home Realm Discovery (HRD). In complex environments and for staged rollouts, client-side registry settings can be used to achieve the same goal.

Further reading

Tutorial: Configure hybrid Azure Active Directory join for managed domains
Tutorial: Configure hybrid Azure Active Directory joined devices manually
Post configuration tasks for Hybrid Azure AD join
Step-by-Step guide to connect down-level devices to Azure AD (in hybrid environment)
How can I locate Service Connection Point for Azure AD connect?
Azure AD Connect: Enabling device writeback