Positioning Azure AD Connect for Mergers and Acquisitions

Many Microsoft-centric organizations have adopted Office 365 services for messaging and collaboration to some degree. Much of the demand for Office 365 professional services these days is generated by merger and acquisition activities. The common scenario is Company A acquires Company B and Company C and then wants to move them both into Company A’s Office 365 tenant so they can start collaborating like a unified organization. However, Company B and Company C have their own distinct infrastructures with their own Active Directory forests to contend with. Getting disparate organizations aligned into a single Office 365 tenant can be challenging, but Microsoft has given us the tools to get the job done. Let’s investigate how to unify organizations under Office 365.

Unifying Organizations With Azure AD Connect

Azure AD Connect is a free tool that connects on-premises Active Directory objects to Azure Active Directory. The tool leverages a wizard that deploys and configures pre-requisites and components required for the connection, including synchronization and sign on. This facilitates a common identity for users of Office 365, Azure, and other SaaS applications integrated with Azure AD. Azure AD Connect can sync multiple domains or even multiple forests to a single Office 365 tenant/Azure AD instance. This capability is key for the merger and acquisition scenario I just described.

Azure AD Connect is capable of synchronizing users and groups from disparate forests into a single Office 365 tenant. Therefore, having an Azure AD Connect server in each forest is not necessary and having multiple servers sync to a single tenant is not supported, even if these servers are configured to synchronize a mutually exclusive set of objects. Additional Azure AD Connect servers are permitted only when deployed in staging mode, where the sync engine runs against the connected domains but doesn’t make any changes. It is comparable to running a PowerShell command with the -whatif switch at the end to get the output without executing the command.

In our common scenario Company A is acquiring other companies and migrating them into a consolidated Active Directory and Office 365/Azure AD infrastructure. The figure below illustrates how:

• Multiple Active Directory forests are joined together with Company A in a hub and spoke trust architecture.

• All forests are synchronizing users and groups to Office 365/Azure AD via Azure AD Connect.

Figure 1. Common M&A Scenario

Active Directory Consolidation

Now what happens when the decision is made to consolidate all users into a single Active Directory forest or domain? In our common scenario, that means users must be migrated to the Company A forest without losing access to Office 365 services. In the past, one of the biggest challenges in migrating Active Directory users subscribed to Office 365 services between forests was preserving the sync relationship between on-premises users and cloud users during this process. Until May of 2017, Office 365 used the objectGUID attribute of Active Directory users to hard match on-premises users to existing cloud users. Azure AD Connect would sync that attribute and store it in its metaverse version of user objects as the sourceAnchor attribute. In Office 365, this attribute would be base-64 encoded and stored as the immutableID attribute.

Figure 2. Source Anchor

The problem with this mapping is that the objectGUID identifier contains values that are unique to each forest and not transferrable in a forest migration scenario. Therefore, when a user gets migrated from one forest to another, their objectGUID must change and break the sync relationship with their Office 365 account. In this scenario, additional effort was required to make Office 365 user accounts’ immutableID writeable by moving the user to the recycle bin (soft-delete) and then overwriting the immutableID with the base-64 encoded version of the objectGUID from the new forest user object.

Microsoft addressed this pain point in Azure AD Connect version 1.1.524.0 (and later) by facilitating the use of ms-DS-ConsistencyGuid as the sourceAnchor attribute for user objects. Installing Azure AD Connect in Express mode will result in ms-DS-ConsistencyGuid being used as the source anchor. When installing in Custom mode, selecting the “Let Azure manage the source anchor for me” option will achieve the same result as the Express settings. Azure AD Connect populates the ms-DS-ConsistencyGuid in Active Directory by writing a user’s objectGUID value back to this attribute. This attribute’s value can be transferred during forest migrations and its portability makes migrating users between forests much simpler.

Matching Users With the “Mail” Attribute

Hard matching users is important for keeping users synced during migrations. Soft matching is how users are matched when new users are provisioned. Using the default configuration, Azure AD Connect will use an on-premises user’s universal principal name (UPN) to derive their Office 365 username. This is problematic in a multi-forest scenario where users are migrating between forests because of UPN name suffix routing across the trusts. UPN suffixes can’t exist on both sides of a forest trust relationship. When that happens, name suffix routing across the trust stops working completely. In that case, name suffixes listed in the Name Suffix Routing tab under the trust’s properties in Active Directory Domains and Trusts will show a status of “disabled” under routing and “conflicting” under status.

In a fluid multi-forest scenario, configuring Azure AD Connect to use the “mail” attribute to match users instead of UPN alleviates this issue.

Figure 3. Azure AD Connect user matching

The mail attribute is more portable between forests than UPN and more flexible when changes need to be made. It also fits Microsoft’s standard approach of telling users to “log in with your email address.” It should be noted that newly provisioned users in Active Directory will be ignored by Azure AD Connect until their mail attribute is populated.

Sync Conflicts

In a merger or acquisition scenario, it’s common for individuals to have users provisioned in multiple forests as a shortcut for granting access to applications. If Azure AD Connects detects conflicting user objects from two different forests in this scenario, it will sync one object and ignore the other one. It will not attempt to merge them. Azure AD Connect assumes it has been installed in the target or hub forest, so it will automatically choose to sync the user object in its native forest when a conflict arises. This gives administrators flexibility in deciding whether source forest users should be moved to an OU not synced by Azure AD Connect or disabled during migrations. Administrators should keep this in mind when deciding where to install Azure AD Connect.

Moving Toward Unification

Getting started down the road toward unification of applications and directories can be challenging. Whether you already have a merger and acquisition technology strategy or need some help in this area, Credera would love to be part of your transformation journey. Feel free to contact us at findoutmore@credera.com to learn how we can work together to accomplish your goals.

• Mergers And Acquisitions
• Azure AD
• Microsoft Office 365