The Hard Part of Soft Matching between Active Directory and Azure AD

One of the pieces of feedback we received from a previous ENow post (integrating your temporary COVID tenant with your on-premises environment), was the fear of introducing errors and interrupting processes that now rely on the Azure AD tenant. This, indeed, may be the case when you rely solely on Azure AD Connect’s soft matching capabilities and wield a narrow scope for synchronization of objects.

Let me explain.

The initial state of your Azure AD

When integrating an Azure AD tenant with an Active Directory environment, you’re bound to start with the situation where you have accounts on both sides that you need to combine. You encounter this situation when you’re integrating your COVID Azure AD tenant with your AD, but you might also find self-service accounts in Azure AD when performing a straightforward Hybrid Identity implementation.

As an admin, taking ownership of an Azure AD tenant means you’re going to actively manage and monitor the Azure AD tenant. This includes taking care of any objects you may or may not feel are in scope of your work. If you don’t, people may find themselves confronted with changed passwords, a different sign-in method suddenly pointing to the corporate federation solution, and/or lockouts.

Approach

The approach to combining the objects in both Active Directory and Azure AD consists of three steps:

1. Match userPrincipalName suffixes in Active Directory to Azure AD Custom domain names
2. Communicate to people with self-service accounts
3. Match objects in Active Directory to objects in Azure AD

Matching and fixing userPrincipalName suffixes

Microsoft’s strong recommendation is to align the userPrincipalName attribute with the user object’s primary email address in Active Directory. This way, the on-premises userPrincipalName can be used in Azure AD.

In Active Directory, you can add additional userPrincipalName suffixes. This is the part in a user object’s sign-in name and email address after the ‘@’. Your organization may struggle with *.local Active Directory domain names or other DNS domain names that your organization doesn’t own or that aren’t registrable DNS domain names. In this case, you should add the DNS domain names your organization does own and use in its email addresses. Then, you should change the userPrincipalName attributes for all user objects in scope for synchronization to Azure AD to match their email addresses.

This is the point where things may break on-premises. Applications might have objects stored with the old suffixes in their databases, services may be programmed with hardcoded suffixes, etc. Luckily, you can test these changes with a small pilot audience and you can revert changes quickly.

Taking care of self-service accounts

The quintessential step to taking ownership of an Azure AD tenant is verifying the DNS domain names of your organization as Azure AD custom domain names in the Azure AD tenant.

No doubt, when you verify DNS domain names that resemble your email domains, you’ll face self-service accounts. These accounts have been created by people in your organization in the past when:

• they were invited to use functionality together with other organizations;
• they entered into a trial period for a Microsoft cloud license, and/or;
• they manage(d) Microsoft cloud licenses for your organization.

People have provided a password for these self-service accounts and have already setup multi-factor authentication to prevent getting locked out from their accounts when they forget these passwords. They use these passwords to access the functionality. These passwords may or may not be different from their passwords in Active Directory.

If your goal is to only synchronize a few objects from Active Directory to Azure AD, you should include the user accounts in Active Directory for people with Azure AD self-service accounts in the synchronization scope of Azure AD Connect. This way, you eliminate shadow IT and provide the benefits of single sign-on to these people.

During your project, their sign-in experience changes. When Azure AD Connect matches up these accounts to their on-premises accounts based on their email address, their sign-in method changes from cloud-only to:

• Password hash synchronization;
• Pass-through authentication, or;
• Federation with AD FS, PingFederate or a 3^rd-party federation solution.

In the first two cases, their passwords may change. In the third case, they get redirected to the federation sign-in experience when they access Azure AD and Azure AD-integrated applications, services and systems.

If the email address they registered their self-service account with doesn’t match the primary SMTP address for their Active Directory account, you should change one of these values. From my experience, changing the sign-in name in Azure AD is the way to go.

You should communicate the changes in sign-in name and sign-in method to them beforehand, together with a clear point in time for these changes. It goes without saying that I think you should automate and test these steps. From my experience, PowerShell suits this job well.

Matching objects

With the email addresses and userPrincipalName attributes aligning for your people, Azure AD Connect will automatically match any on-premises object in scope with the pre-existing Azure AD object through soft matching.

Soft matching

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

1. The userPrincipalName attributes match for both objects;
2. The userPrincipalName attribute for the user object in Active Directory matches with the primary email address (denoted with SMTP: in the proxyAddresses attribute) of the Azure AD user object, and/or;
3. The primary email address (denoted with SMTP: in the proxyAddresses attribute) for the user object in Active Directory matches the userPrincipalName of the Azure AD user object.

There are scripts available that will check these matches and report on any mismatches. For mismatched objects, all is not lost. There’s also the ability to hard match.

Hard matching

Azure AD Connect and other synchronization solutions between Active Directory and Azure AD use the construct of a source anchor attributes. The source anchor is specified when Azure AD Connect is configured. This source anchor attribute acts as the end-to-end matching construct.

During normal operations, the source anchor object defaults to the mS-DS-ConsistencyGuid attribute for Active Directory objects. Upon initial synchronization of user objects and group objects by Azure AD Connect, the base64 representation of the objectGUID value is written to:

• The mS-DS-ConsistencyGuid attribute for the Active Directory object, and;
• The ImmutableID attribute of the Azure AD object.

However, the mS-DS-ConsistencyGuid and ImmutableID attributes can be filled manually by entering the same value to the source anchor attributes of the objects in both directories.

This is hard matching. The userPrincipalName and primary email address attribute are ignored; soft matching does not occur. Azure AD Connect creates the match between the on-premises Active Directory object and the Azure AD object at the admin’s request.

Thinking before acting

The previously mentioned approach requires thinking before acting. The configuration of Azure AD Connect can be erroneous without verified DNS domain names without the proper userPrincipalName suffixes and without the right values for the userPrincipalName, proxyAddresses and mS-DS-ConsistencyGuid attributes.

In the last case, mismatches may occur. This may introduce improper access for unauthorized people and interruptions of critical processes like software asset management; an admin’s nightmare. Hard matching is the way to go when you foresee issues with soft matching.

Active Directory Monitoring and Reporting

Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Active Directory Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.

Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.