First experience with Azure AD Connect Cloud Provisioning
Introduction to the new cloud based synchronization technology
Microsoft has released a new tool for object synchronisation in November 2019. A new and additional way for object synchronization. Is it a successor for the well known swiss army knife Azure AD Connect Server (AAD Connect)? In my opinion, not yet, but who knows what will happen in the future?
I have extended my lab environment with cloud provisioning to keep an eye on that initial release. Here is what I have found out and I will share this from an vendor independent point of view. All details about Cloud Provisioning like requirements or setup instructions can be found in Microsoft Docs start here
Before we get into Cloud Provisioning details let’s talk about Azure AD Connect Server for a bit.
Sync Service History
The basis of AAD Connects server is the MIM Synchronization Service. It was first launched as the heart in the Microsoft Identity Product Family, which has a long history in the Microsoft Identity Portfolio.
This Product Family was launched in 2007 under the abbreviation ILM 2007 (Identity Lifecycle Manager) and it was at that time a combination of the tools MIIS 2003 (Microsoft Identity Integration Server) and CLM Certificate Lifecycle Manager. In 2010 Microsoft has integrated the products into the Forefront range and the Forefront Identity Manager (FIM) was born. By discontinuing the Forefront portfolio, Microsoft announced in 2014 that FIM would be renamed and will now be developed further under a new flag and the name MIM (Microsoft Identity Manager).
The last version of Microsoft Identity Manager was released in 2016 , which still includes an inconspicuous but very important service, the aforementioned synchronization service. It has survived all of the product cycles mentioned and it is currently twice in the Microsoft product portfolio: once on the MIM Server Binaries, in the just described variant, and when you install Azure AD Connect. A version adapted to the Azure Active Directory lands on the designated server to have the user information ready in Azure Active Directory.
In my opinion the entire MIM Identity Familiy (except sync) becomes more and more irrelevant in the shadow of the Microsoft Cloud- and Azure Avalanche and the last version update was released in Oct. 2019. It remains an excitement to see what will happen in the future with MIM. But that’s another story.
Why is this important here?
It is important, because when you setup AAD Connect, you get a core technology (the sync engine) which has almost 20 years of age. Of course, it is not the same in all aspects as it was in the first release of MIIS 2003, because a couple of features were being added by Microsoft to let the service fulfill specific hybrid Azure requirements: Passthru Authentication Agent is one example or the Azure AD Connect Health Agent and a few other features. But under the hood the Synchronization Service is still the same. Do not misunderstand this. For me AAD Connect is rock stable and I have implemented it a couple of times for several customers. It is one of the tools that you can setup and let them stand in the corner and forget it, it runs and runs and performs very reliable. There is nothing to criticize about this established technology. Nevertheless we want to know what Cloud Provisioning could do for us.
In a nutshell
When you go thru the comparizon table you can find that Cloud Provisioning is not a competitor to Azure AD Connect. On the contrary, it makes lot of sense to have both technologies implemented in an environment with a couple of scenarios.
You can describe it like this:
Cloud Provisioning is a synchronization method, managed from the cloud, with just a tiny agent on a member server and with an easy way to implement high availlability.
I guess this describes the solution best.
Azure AD Connect cloud provisioning can be installed in an environment with an already existing Azure AD Connect server. The admin must take care that the OUs processed by AADConnect are not in the sync scope from Cloud Provisioning and vice versa. A how to deployment guide, with the specific rule configuration to can be found here Setup in an existing synced forest
Top 5 functionalities
For me, the most important aspect is the single point of administration, integrated into the Azure Portal. But there is more and I have picked 5 additional top functionalities.
Local components
Azure AD Connect is implemented on a member server or on a domain controller On-Premises. This can be an advantage, because you have a maximum of flexibility and independent redundance. When you go on maintenance with the active AD Connect Server for example or when you are developing and testing some filtering rules. A staging server can help in such scenarios, because it acts like a fully sync server, but without writing anything to the connected local Active Directory Domains or to the Azure Tenant. But it can be a trap aswell. The reason why the advantage of the staging server can become a disadvantage is that you have to take care that each configuration on all AAD Connect Servers is identical to the others. When you switch a staging server to an active server you must be rest assured that the box accomplishes the same as the former active server, without any surprises. And this requires that each config needs to be done manually on each server. The Azure AD Connect Documenter can be a helpful tool to find differences, but in the end the config must be made manually.
I will not go too much into detail with the staging technology, the complete story can be found in this article.
But you can forget this aspect with Azure AD Connect Cloud Provisioning! I would say one of the pretty cool differences with that technology is that Microsoft got rid of the server based setup and they have moved the setup to the Azure Portal as a central point. The only thing that you have to do ist to download a tiny agent and install it on the server in the domain that you want to synchronize. There are a couple of requirements, yes, networking ports and URLs that need to be accessed for example, but it is really simple to implement.
And, by the way, you have no SQL discussions when you plan for Cloud Provisioning.
No service hardening
Azure AD Connect uses a couple of service accounts on a Synchronization Server. One is for the service itself, and one for each Management Agent (MA), which will be used for writing operations into the connected Directory where the account belongs to.
The most critical account here is for me the account which is used for the On Premises Directory MA, because it has the permission to make bulk updates to the Active Directory Domain. Microsoft has an valuable article with recommendations on how these accounts can be hardened.
But this is no longer an aspect with Cloud Provisioning, since there are no configurable Management Agent Accounts that increase the security very well.
Filtering with security groups
Part of the Azure AD Connect Server Setup is the well known Rule Editor. A powerful tool to configure filtering on an attribute basis or to setup attribute transformations within in the synchronization process. Cloud Provisioning in the current version has none such rule editor to configure attribute filtering, in a way similar to Azure AD Connect. But there is another cool option to implement filtering: the good old way to use domain groups. This is in a similar way also possible with Azure AD Connect. It is called Pilot setup and it is availlable when the setup of AAD Connect runs the first time. But this is not recommended for production environment and it is only an option for starting with the synchronization process for a small number of objects. The group cannot be changed and more then one group is also not possible.
In Cloud Provisioning you can use groups for filtering in several ways. Multiple groups and the groups can also be aligned later.
No trust relationships
When an additional domain must be taken into an existing synchronization setup, maybe in case of a merger, the new domain must be trusted to the domain where the Azure AD Connect Server is installed. Cloud provisioning allows adding new domains from untrusted environments, especially when you are targeting an existing tenant. This makes setup of new domains very easy and it is another very big advantage and key feature.
Simplify High Availability Deployment
The deployment of new agents to an additional member server in the source domain, which needs to be synchronized, is very easy. Download the binaries from the Azure Cloud Provisioning Portal and install it on a machine. A short configuration and that’s it. This makes especially sense in an enviroment for High Availlability where Password hash sync is enabled.
But don’t forget, it’s Preview
Cloud Provisioning has a lot of cool features and it can be an enrichment to every Azure hybrid identity setup. The current Public Preview has lot of features from AAD Connect not implemented. But is this required at the moment? I don’t think so, because a side by side setup with both technologies is possible and and Cloud Provisioning brings additional features to extend the overall possibilities
