Azure AD Connect is Microsoft’s free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments and LDAP v3-compatible directories to Azure Active Directory.
On December 5th 2019, Microsoft introduced Azure AD Connect Cloud Provisioning. After playing around with it,’I’m sharing ten things you’ll want to need to know about it, before deploying it to address your organizations’ needs.
About Azure AD Connect Cloud Provisioning
Azure AD Connect Cloud Provisioning is a new Microsoft agent for synchronization of users, groups and contacts to Azure AD. It can be used alongside Azure AD Connect sync.
In contrast to Azure AD Connect, the database, rules and engine is not placed on a Windows Server installation on-premises, but within the Azure Active Directory infrastructure. This agent setup makes it lightweight, fast to deploy and easy to manage.
Microsoft main goal with Azure AD Connect Cloud Provisioning is to provide synchronization for non-reachable Active Directory forests and synchronization for Active Directory forests for recently acquired organizations. In the real world, these scenarios mostly overlap.
Ten things you need to know
Azure AD Connect Cloud Provisioning sounds perfect, but in reality, there are a couple of things you’ll want to know before deploying it to address your organizations’ needs:
Azure AD Connect Cloud Provisioning Public Preview
Azure AD Connect is currently in Public Preview. This means that Microsoft doesn’t really want you to deploy in production, just yet.
When looking at Conditional Access Baseline Policies, you might want to hold off on embracing public preview functionality, as they might change at any moment (the granular Conditional Access Baseline Policies become Security Defaults).
Also, looking at Azure MFA’s Hardware Token functionality, some functionality stays in Public Preview for an awful long time. As you lock your organizations’ strategy on these features, you might face architectural debt.
Automatic Upgrades
Many organizations want to control updates to their environment. That is why we developed a method to Leverage Azure AD Connect Staging Mode for Release Management. For Azure AD Connect Cloud Provisioning, though, this is not an option. The lightweight agent will self-update automatically.
Schedule-driven
With every new synchronization solution, I’m hoping for an event-driven synchronization engine, that springs into action when something changes in the source directory, database and/or repository and then flows information out to wherever it needs to be.
To my disappointment, Azure AD Connect Cloud Provisioning is still schedule-driven. It employs a much shorter interval for querying the Active Directory database, when compared to Azure AD Connect, but it is still schedule-driven.
In contrast to Azure AD Connect with its Start-ADSyncSyncCycle PowerShell cmdlet, Azure AD Connect Cloud Provisioning doesn’t support on-demand synchronization. If the schedule doesn’t suit your organizations, you’re out of luck.
No password write-back
The Azure AD Connect Cloud Provisioning agent shows a complete lack of write-back features, While this suits organizations with Windows Server 2008-level Active Directory forests (and below), this is quite bothersome for organizations that want to deploy Azure AD Self-service Password Reset (SSPR).
No delegated Service account
Azure AD Connect has the option to run its service as a group Managed Service Account (gMSA) and connect to Active Directory through delegated service accounts. While Express Settings leave some gaps, it’s perfectly manageable and sufficiently securable.
In contrast, the Azure AD Connect Cloud Provisioning agent doesn’t work with a delegated account. The credentials you enter when you configure the Azure AD Connect Cloud Provisioning agent are the credentials used.
No integration with Azure AD Connect Health
As you might expect, Microsoft’s Pass-through Authentication agent shares many technological innovations with the Azure AD Connect Cloud Provisioning agent. Another commonality is their lack of integration with Azure AD Connect Health.
The Azure AD Portal will show you perfect green checks when the agent is able to communicate with the Azure AD infrastructure. However, the green check you see doesn’t mean the agent is able to communicate with Domain Controllers…
No accidental deletion prevention
Azure AD Connect offers a limit known as its Export Deletion Threshold. When the threshold is reached while running an Export operation (writing to a connected directory), Azure AD Connect stops synchronizing to prevent further harm.
The default limit of 500 objects might not suit every organization, but it’s still much better than having no limit at all. In case of a misconfiguration, it might mean that all objects synchronized by an Azure AD Connect Cloud Provisioning agent might be accidentally deleted or converted to cloud-only objects.
Not available in the China and Government tenants
Currently, the Azure AD Connect Cloud Provisioning agents cannot be used in combination with Azure AD tenants that are part of any of the sovereign clouds:
- Azure AD for US Government
- Azure AD China, operated by 21Vianet
- Azure AD Germany
No PowerShell capabilities
In more recent versions, Azure AD Connect gained some strong PowerShell capabilities. However, it’s still not possible to deploy Azure AD Connect using just PowerShell, install it on Server Core installations or in containers.
Azure AD Connect Cloud Provisioning agents lack all PowerShell capabilities.
Backup and Restore difficulties
Many organizations are now seeing the need for backup and restore of their data in Azure Active Directory. Solutions to backup data in Office 365 are abundant these days, but only Quest has a solution for Azure AD.
When sticking configuration in the cloud that involves on-premises resources, the ability to rebuild, redeploy and restore depends on the capabilities offered by the cloud platform. For Azure AD Connect Cloud Provisioning, the ability to create backups is non-existent. As far as the other scenarios are concerned, they all rely on these backups, so they are no-go areas at the moment.
Login