AD Connect Cloud Provisioning: Preview

This week saw the (preview) release of Azure AD Connect Cloud Provisioning. For those still catching up on Microsoft Ignite news those words might not mean much to you. Dig a little deeper though and you’ll realise that this is a big deal. From my perspective it was one of the biggest bits of news to come out of Ignite, and something I made reference to in the highlights video that Transparity" posted while we were out in Orlando.

A challenge faced by an number of organisations, is what to do following a merger or acquisition. We live in an age where this activity is common, and poses a real challenge to many IT departments. Businesses expect the rapid coming together of infrastructure(s) to provide a simple and seamless experience for end users. This often begins with communication and collaboration capabilities; email, file sharing, and messaging services like Microsoft Teams.

There are two perspectives to achieving this with Microsoft Cloud. On the one hand it can be seen as a simple enabler for the coming together of these common services. On-premises data and applications that take considerable time and effort to consolidate can remain as is, whilst front end services can be stitched together via the cloud. A facade in some respects, but one which can be ultra-effective in M&A scenarios where perception is key. On the other hand, this process can be as fraught with complexity as the back-end systems being deferred. Central to its success is the ability to consolidate user objects into a common Azure AD. Simple if you can meet the prerequisites. Painfully difficult if you don’t.

What are the Challenges?

Any mid-large scale organisation will be familiar with Azure AD Connect (AADC). In ultra-simple terms, AADC provides for the synchronisation of user objects and passwords from an on-premises Active Directory, to Azure AD. Without it you are forced to manually manage multiple identities for end users - one on-premises for local resources, and one in the Cloud for Microsoft 365 and other connected services. AADC bridges these two environments - providing for password synchronisation, automatic user provisioning, and similarly de-provisioning / blocking of users when they leave.

AADC supports a multi-forest model - meaning you can synchronise objects from multiple local Active Directory environments. There’s one key caveat though. The Active Directory environments must all be capable of being referenced by a single AADC instance. The deployment of multiple AADC instances synchronising objects into a single Azure AD is not supported:

For some organisations, this is relatively simple to fix. You can connect all sites to an Azure environment and deploy DC’s for all, alongside a central AADC instance. Alternatively you can connect the remote forest(s) to the on-premises environment hosting an existing installation of AADC via VPN / MPLS. There are various things that can complicate this though - networking constraints or company politics to name just a couple…

How does Azure AD Connect Cloud Provisioning help?

Azure AD Connect Cloud Provisioning is an entirely new approach to user synchronisation. It does away with the 1:1 limitation of AADC and Azure AD. It also removes the need to host an AADC instance at all for those organisations looking to simplify their approach to hybrid identity. It’s entirely new, and entirely welcome for those complex, or politicised organisational coming-togethers.

Through the deployment of on-premises agents, we can now connect multiple, distributed Active Directory environments to a single Azure AD. The provisioning configuration is stored in the cloud and managed as part of the service. There’s no more local processing.

We can also deploy multiple agents - providing for high-availability in much the same way as we can with the Pass-Through Authentication (PTA) agent.

Are there any limitations?

The short answer is yes. Several as it happens, although I’m hopeful at least some of these will be addressed during the course of the preview. Key limitations from my perspective are as follows:

• No support for Device Objects (users, groups, and contacts only)
• No support for pass-through authentication (whether you should be using this or not is worthy of another blog post…)
• Filtering is possible only via Domain, OU, or AD Group, not by attribute
• Writeback isn’t supported (perhaps the biggest constraint in my opinion…)

A full summary of the available features, along with a comparison matrix vs. Azure AD Connect can be found here.

How can I get started with Cloud Provisioning?

If you haven’t seen it already, you can read the Tech Community blog post from [Alex Simons](https://twitter.com/Alex_A_Simonswhere he discusses cloud provisioning in more detail. The service itself is accessed through the Azure AD Connect section of the Azure AD portal:

From a configuration perspective there are two key steps:

• Deploy the Provisioning Agent
• Configure a Cloud Provisioning profile, specifying domain, filter, and password hash synchronisation options

A deployment guide covering both of the above steps is available on Microsoft Docs: Installing AD Connect Cloud Provisioning.

In Summary…

Azure AD Connect Cloud Provisioning is an entirely new approach to the synchronisation of users and passwords into Azure AD. It enables new use cases, deals with some significant constraints in AADC, and provides some insight into Microsoft’s strategy for user provisioning moving forwards. It’s a big deal.

Is it perfect? No, but it’s early days. It’s also only in preview… Current caveats aside (of which there are many), it’s well worth considering for those organisations who find themselves at the sharp end of M&A activity.

Take a deeper look, consider giving it a go, and let me know what you think!