Since the dawn of Office 365, synchronization from on-premises Active Directory has been performed by using server software installed on local servers running a trimmed-down version of Microsoft’s identity sync engine, Microsoft Identity Manager (MIM) – or as it was formerly known MIIS and FIM. In the earliest days of Office 365 in Live@EDU, this was called OLSync, before becoming DirSync, then Azure AD Sync and – as it’s known today – Azure AD Connect. Fundamentally this required the installation of a SQL Server instance along with the provisioning engine and extensions, for features like Password Hash Sync and Self-Service Password Reset.
This model has a number of limitations – only a single active Azure AD Connect server can be running against a single Azure AD and Office 365 tenant, and if you are synchronizing multiple directories, then Azure AD Connect needs to be able to connect over the network to domain controllers in each AD forest. This means it’s not got a built-in high-availability model and is less good if you have a diverse, disconnected organization.
Azure AD Connect Cloud Provisioning modernises the synchronization model taking away the heavy lifting from on-premises into the cloud, with one or more agents installed within each Active Directory domain that Azure AD reaches out to using Azure AD Application Proxy to trigger sync jobs.
Not only does this fundamentally move away from the previous model, it provides High Availability and crucially makes it much easier for organizations going through mergers and acquisitions to synchronize to a single Azure AD and Office 365 tenant.
This limitation often meant that organizations with lots of AD forests looked to third-party SSO platforms like Okta to fill the gap. The big question is, will Azure AD Connect Cloud Provisioning help those organizations? From a first look – yes it will.
Before we continue – Azure AD Connect Cloud Provisioning is in preview which means you should not use it in a production environment. But when it is released you will want to be prepared to use it and aware of some of the limitations it has at present.
Fundamentally there are some core limitations that exist with the preview today. These include no support for device objects, no support for pass-through authentication, no support for write-back, limited support for customizations and crucially no support for Exchange Hybrid Configurations. You can read the full list of limitations here.
In this article, we’ll walk through the setup process for multiple forests and explore what happens when we try out some of the common configurations (including what happens if we do try Exchange Hybrid) that might trip you up.
Our example environment for Azure AD Connect
For this article, we’ve built out three lab environments, running the following versions of Exchange Server:
Lab 01 running Exchange 2010
Lab 02 running Exchange 2016
Lab 03 running Exchange 2019
Each of these are published independently to the internet and would be ready for installation and configuration of Azure AD Connect and Exchange Hybrid – all relevant ports to Office 365 services have all been allowed for.
We’ll assume though that in our example environment that each AD and Exchange forest are on separate networks without WAN or LAN connectivity – perhaps they are the result of a three-way merger and as yet have not been able to connect up their networks, but have a goal of using a single identity platform in Azure AD.
Crucially at this point – each Active Directory and Exchange environment contains both unique users and unique domains. We don’t have (for example) user accounts for the same people in each directory. However – we’ll explore later on what happens if we do.
As a core pre-requisite, we’ve setup an Office 365 E3 tenant and registered each environment’s custom domains successfully: