This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here.

Microsoft 365, like most technologies, relies heavily on Identity. Maintaining a directory of users, passwords and metadata is key to the operation of business applications. Azure Active Directory is the Identity Provider (IdP) underpinning the Microsoft 365 stack. That’s where all our users live and where we collate data such as email addresses, display names etc.

When you create a Microsoft 365 tenancy, you will automatically be provisioned with an Azure AD instance under the hood and you can go ahead and create your users and populate their details – easy! Most organizations however, already have an on-premises Active Directory, containing all this information – particularly, usernames and passwords – and it doesn’t really make sense to maintain a completely separate directory for cloud services, right? This is where Azure AD Synchronization comes in, we use the Microsoft AD Connect tool to regularly synchronize our user accounts and metadata from local AD to Azure AD.

How To Determine If You Should Synchronize Directories

Some of the considerations you will need to take into account when deciding if you should synchronize directories:

• Do you have on on-premises Active Directory?
  • This one is pretty obvious
• Are you planning an Exchange Hybrid?
  • While not 100% required for migration, an Exchange Hybrid topology relies on AD Connect to ensure the correct Exchange Attributes are in place in both directories for your users
• Do you require Same / Single Sign-on?
  • More detail on sign-on options in this post
• Do you require ADFS for authentication
  • Federation to Azure AD requires Synchronized identities
• Is there a reason you need to maintain two separate directories?
  • There are some use cases for not integrating directories but they are few and far between

AD Connect Topology

At a high level, the recommended topology of AD Connect for a flat AD Domain structure looks like this:

You may have two AD Connect servers with one in staging mode for fault tolerance but at a high level, it’s pretty straightforward.

Unfortunately, in the real world, very few organizations – particularly at the Enterprise level have a simple, flat domain/forest structure. Large Organizations could have multiple forests, multiple forest trusts, untrusted forests integrated and even multiple tenancies. There are, however, a number of supported topologies to meet pretty much every conceivable Domain / Forest configuration.

Multi-Forest – Single-Tenant

A common scenario with large organizations, particularly with ongoing mergers, acquisitions and divestitures is a group of Active Directory forests, trusted or untrusted, connecting to a single tenancy.

In this topology, there is a single active AD Connect server (and potentially a second server in staging mode) which has connectors added for each of the forests/domains it will synchronize from. The AD Connect server uses a service account in each forest so does not require a domain / forest trust between the source forests. Users are synchronized from each source into the AD Connect database (metaverse), validation is run against the imports and then changes are provisioned. When choosing this topology, there are a few things to be aware of:

• Generally, conflicts for attributes which must be unique will be resolved by AD Connect at a ‘first come first serve’ basis. AD Connect will provide an error when a unique attribute is detected across multiple directories
• User accounts are matched to Azure AD Identities by default using the attribute MS-DS-ConsistencyGUID, this can be configured when installing AD Connect but it is not recommended to change this. This is called the sourceAnchor – in older versions of AD Connect and DirSync, the ObjectGUID attribute was used as the sourceAnchor but this was not very flexible as the ObjectGUID in AD could not be changed, making migrations and matching up accounts to existing identities troublesome

• If the same user account exists in the synchronization scope across multiple source forests, only one of the identities will be synchronized

Multi-Forest – Multi-Tenant

If the organization requires separation of Azure AD / Microsoft 365 users from different source directories (such as an MSP who provides AD Domain Services to multiple customers), a multi-forest – multi-tenant approach can be used, really this is just multiple instances of single-forest – single-tenant topologies, not much more to it.

Single-Forest – Multi-Tenant

This topology is probably the most complex, a single Active Directory Forest linked to Multiple Azure AD instances. Generally this topology would be used where we need to segregate data storage for users within a single forest or to facilitate tenant to tenant migrations.

Important: To implement a single-forest – multi-tenant topology, we need to use AD Connect filtering rules to ensure that any object is only synchronized to one tenant at a time. Synchronizing a single object to multiple tenancies is not supported.

Other things to be aware of with this topology:

• Object filtering rules should be mutually exclusive, ensuring that no objects can be synchronized to more than one tenancy at a time
• As the public domain can only be registered to a single tenancy at a time, keep in mind the UPN suffix used in each tenant and in your directory
• Exchange Hybrid can only be enabled to one of the tenancies at a time
• Group Write-Back is only supported with a customized configuration with separate Organizational Units specified
• Device Write-Back is not supported

AD Connect Synchronization Optional Features

Now that we have our topology, we need to figure out what synchronization optional features we need. This can be configured from the AD Connect Wizard. If AD Connect is already installed, we can rerun the wizard to modify sync options.

The optional features available to us in AD Connect are:

• Exchange Hybrid Deployment – This is required to run an Exchange Hybrid Configuration. Enabling this feature will synchronize a large set of attributes, required to support Exchange Hybrid to Azure AD. If you are planning to use Exchange Online, ensure to enable this before synchronizing and licensing users
• Exchange Mail Public Folders – Enabling this option allows AD Connect to Synchronize Exchange Public Folder objects to Azure AD. This is used when we require the use of Public folders in a Hybrid Exchange Configuration
• Azure AD App and Attribute Filtering – App and Attribute filtering allows us to tailor the scope of our synchronized attributes to meet the requirements of our specific Microsoft 365 apps. This can both speed up the synchronization process when we are only using a subset of apps and limit the data that is provisioned to Azure AD to what we require
• Password Hash Synchronization – This option enables Password Hash Sync as detailed in this previous post
• Password writeback – Password Writeback allows AD Connect to write back passwords which have changed in Azure AD, to the on-premises directory. This is required to enabled self-service password reset for example
• Group Writeback – This option will synchronize Office 365 Groups back to a selected on-premises OU. This is particularly useful to manage Office 365 groups from on-premises AD
• Device Writeback – Device Writeback allows AD Connect to Synchronize device objects from Azure AD back to the on-premises directory. Devices provisioned in Azure AD will be made available on-premises for things like ADFS Device-Based Conditional Access
• Directory Extension Attribute Sync – Directory Extension Attribute Sync allows us to modify the set of attributes we synchronize to Azure AD. This is useful when we want to synchronize additional data such as Extension Attributes from AD for use in Azure AD

Other AD Connect Features

Outside of the standard sync options, there are a few features of an Azure AD Connect installation to be aware of.

• AD Connect installations have a built-in deletion threshold set to 500 objects by default. This means that if AD Connect picks up more than 500 projected deletions in a particular synchronization run, the sync process will stop with a deletion threshold error. This is a safety feature to prevent accidental mass deletions from an AD Connect or AD change. It can be disabled or changed if required but should only be disabled temporarily. More information on the deletion threshold here
• AD Connect Synchronization Rules can be modified to change sync scopes or attribute flow. This can be tricky and is not really recommended without full knowledge of the impact of the configuration. One use case is to add a filtered scope to exclude or include objects to support a single-forest – multi-tenant topology
• Filtering the sync scope based on group membership is available but is only supported during rollout, future changes to AD Connect will not allow re-enabling of Group-level filtering