Azure AD Cloud Sync First impressions
This blog post overviews the Azure AD Cloud Sync, some configurations, and first impressions from the field.
Do you remember the days with the first directory synchronization method? For example, the one with BPOS on the earlier days of Office 365. Sync objects to the cloud are known from the first days of Microsoft cloud, from the BPOS days, and then with the Office 365 waves editions. Over time, the evolution of the sync components has improved, and these days we’ve got the Azure AD Connect that is doing a great job. But, Microsoft is taking the sync method to the next level, as it should be. Now with Cloud Sync.
Azure AD Connect Cloud Sync
Azure AD Connect Cloud Sync is the new component to execute your hybrid identity and synchronize objects such as users, groups, contacts, and more to Azure AD. It performs the synchronization by using the Azure AD cloud provisioning agent instead of the Azure AD Connect on-prem component/server.
The Azure AD Connect Cloud Sync provides many values, below some of the benefits:
Remove security issues with the Cloud Sync method. The on-prem components (Azure AD Connect Sync) behave like a DC, and because of that, it’s exposed and hackable to many attack paths (in comparison to any other written DC). Shifting synchronization to the Cloud Sync reduces the attack area and significantly minimizes security risks.
Support for synchronizing to an Azure AD tenant from a multi-forest disconnected Active Directory forest environment: The common scenarios include merger & acquisition and companies that have historically had multiple AD forests.
Simplified installation with lightweight provisioning agents: The agents act as a bridge from AD to Azure AD, with all the sync configuration managed in the cloud.
Multiple provisioning agents can simplify high availability deployments, particularly critical for organizations relying upon password hash synchronization from AD to Azure AD.
Support for large groups with up to 50K members. It is recommended to use only the OU scoping filter when synchronizing large groups.
As you know, Azure AD Connect sync is running on a SQL express and is not high-available (more a standby mode). Azure AD Connect sync is the best solution for more prominent companies with complex requirements. But some companies don’t need AD Connect sync to take advantage of the hybrid identity and password hash sync, which can be down via Azure AD Connect Cloud Sync easily.
Microsoft realizes that it is unfortunate that your company’s journey to the cloud-first requires installing more software and components on-premises. Azure AD Connect Cloud Sync is a cloud service alternative to Azure AD Connect server/component.
The organization deploys one or more lightweight agents in their on-premises environment to bridge Active Directory and Azure AD. The settings, configuration, troubleshooting, and other actions are done in the cloud.
The Azure AD Cloud Sync provides some of the features and capabilities like Azure AD Connect provides, for example, useful for some consolidation and acquisition scenarios. It’s important to note that Azure AD Connect Cloud Sync doesn’t support Exchange hybrid (at least for Dcember 2021).
Cloud sync is built on top of the Azure AD services and has two key components:
Provisioning agent is the same as Workday inbound and built on the same server-side technology as app proxy and Pass-Through Authentication. It requires an outbound connection only, and agents are auto-updated.
Provisioning service same as outbound provisioning, and Workday inbound provisioning uses a schedule-based model. In the case of cloud sync, the changes are provisioned every 2 mins.
Azure AD Connect Cloud Sync has many of the same features and capabilities as Azure AD Connect to sync with some differences:
- Lightweight agent installation model.
- High-availability support for multiple agents.
- Allows connectivity to multiple disconnected on-premises AD forests
- Synchronizes directory changes more frequently than Azure AD Connect.
- It can be used in addition to Azure AD Connect.
- No support Exchange hybrid writeback.
- No support LDAPv3-compatible identity stores.
- Does not support device objects (No hybrid Azure AD join or Windows Hello support)
- No support directory attribute synchronization.
- No Pass-Through support Authentication (PTA).
- No support synchronization rule editing capabilities.
- No support writeback for passwords, devices, or groups.
- No support cross-domain references.
Azure AD Connect and Cloud Sync Comparison
The following table provides a comparison between Azure AD Connect and Azure AD Connect cloud sync:
|Feature||Azure Active Directory Connect sync||Azure Active Directory Connect cloud sync|
|Connect to single on-premises AD forest||●||●|
|Connect to multiple on-premises AD forests||●||●|
|Connect to multiple disconnected on-premises AD forests||●|
|Lightweight agent installation model||●|
|Multiple active agents for high availability||●|
|Connect to LDAP directories||●|
|Support for user objects||●||●|
|Support for group objects||●||●|
|Support for contact objects||●||●|
|Support for device objects||●|
|Allow basic customization for attribute flows.||●||●|
|Synchronize Exchange online attributes||●||●|
|Synchronize extension attributes 1-15||●||●|
|Synchronize customer-defined AD attributes (directory extensions)||●|
|Support for Password Hash Sync||●||●|
|Support for Pass-Through Authentication||●|
|Support for federation||●||●|
|Seamless Single Sign-on||●||●|
|Supports installation on a Domain Controller||●||●|
|Support for Windows Server 2016||●||●|
|Filter on Domains/OUs/groups||●||●|
|Filter on objects’ attribute values||●|
|Allow a minimal set of attributes to be synchronized (MinSync)||●||●|
|Allow removing attributes from flowing from AD to Azure AD.||●||●|
|Allow advanced customization for attribute flows.||●|
|Support for password writeback||●||●|
|Support for device writeback||●|
|Support for group writeback||●|
|Azure AD Domain Services support||●|
|Exchange hybrid writeback||●|
|Unlimited number of objects per AD domain||●|
|Support for up to 150,000 objects per AD domain||●||●|
|Groups with up to 50,000 members||●||●|
|Large groups with up to 250,000 members||●|
|Support for US Government||●||●|
Security Considerations with Cloud Sync
Organizations should treat any server running Azure AD Connect or the Azure AD Connect Cloud Sync agent as a tier-0 asset – the same as a domain controller – since it is responsible for directory synchronization with Azure AD. Organizations should restrict administrative access to the Azure AD Connect server to only domain administrators or other tightly controlled security groups.
Azure AD Connect installation and configuration must be run with an Enterprise Admin account in AD and requires a Global Administrator account in the tenant.
Azure AD Connect Cloud Sync must be installed with an AD account with local admin permission on the server or Domain Admin permissions on a domain controller and requires a tenant account with Hybrid Identity Administrator or Global Administrator roles in the tenant.
For Azure AD Connect, the user account used to install it is automatically added to the local ADSyncAdmins security group. The best practice is to add Domain Admins to this group so more than one account can manage directory synchronization. Remove the individual user account to install Azure AD Connect from this group.
The account used for configuration requires specific rights and is only used for installation or configuration. Directory synchronization will not be impacted if the account is disabled or deleted.
Both synchronization solutions use the highest TLS available in Windows Server.
Integrate Cloud Sync
In the Azure Active Directory admin center
Create a cloud-only global administrator account on your Azure AD tenant. This way, you can manage the configuration of your tenant should your on-premises services fail or become unavailable.
Add one or more custom domain names to your Azure AD tenant. Your users can sign in with one of these domain names.
In your on-premises environment
Identify a domain-joined host server running Windows Server 2016 or greater with a minimum of 4 GB RAM and .NET 4.7.1+ runtime.
If there is a firewall between your servers and Azure AD, configure the following items:
- Ensure that agents make outbound requests to Azure AD over the following ports: 443 Handles all outbound communication with the service.
If your firewall enforces rules according to the originating users, open these ports for traffic from Windows services that run as a network service.
- If your firewall or proxy allows you to specify safe suffixes, add connections t to *.msappproxy.net and *.servicebus.windows.net. If not, allow access to the Azure datacenter IP ranges, updated weekly.
- Your agents need access to login.windows.net and login.microsoftonline.com for initial registration. Open your firewall for those URLs as well.
- For certificate validation, unblock the following URLs: mscrl.microsoft.com:80, crl.microsoft.com:80, ocsp.msocsp.com:80, and http://www.microsoft.com:80. Since these URLs are used for certificate validation with other Microsoft products, you may already have these URLs unblocked.
The following is a walk-through of what occurs when the cloud provisioning agent is installed.
- First, the Installer installs the Agent binaries and the Agent Service running under the Virtual Service Account (NETWORK SERVICE\AADProvisioningAgent). A virtual service account is a particular type of account that does not have a password and is managed by Windows.
- The Installer then starts the wizard.
- The wizard will prompt for Azure AD credentials, then authenticate and retrieve a token.
- The wizard then asks for the current machine Domain Administrators credentials.
- Using these credentials, the agent-general managed service account (GMSA) for this domain is either created or located and reused if it already exists.
- The agent service is now reconfigured to run under the GMSA.
- The wizard now asks for domain configuration and the Enterprise Admin (EA)/Domain Admin(DA) Account for each domain you want the agent to service.
- The GMSA account is updated with permissions that enable access to each domain entered above.
- Next, the wizard triggers agent registration.
- The agent creates a certificate and, using the Azure AD token, registers itself and the certificate with the Hybrid Identity Service(HIS) Registration Service.
- The wizard triggers an AgentResourceGrouping call. This call to HIS Admin Service assigns the agent to one or more AD Domains in the HIS configuration.
- The wizard now restarts the agent service.
- The agent calls a Bootstrap Service on the restart to check for configuration updates. The bootstrap service validates the agent identity. It also updates the last bootstrap time. This is important because if agents don’t bootstrap, they are not getting updated Service Bus endpoints and may not receive requests.
Install AAD Cloud Sync
The Azure AD Cloud Sync installation process is very, very simple. Choose your right server, and then install by the process. But, there are a few important settings in the installation process.
Group Managed Service Accounts (gMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management, and delegate the management to other administrators. It also extends this functionality over multiple servers.
TIP: f you allow the agent to create the account, it will be named provAgentgMSA$. If you specify Use custom gMSA, you’re prompted to provide this account.
The Domain Controller side allows you to manage the preference of domain controllers the agent will use by selecting the Select domain controller priority checkbox and ordering the list of domain controllers. Select OK.
The agent has been installed, but it must be configured and enabled before synchronizing users.
Password Writeback – To use password writeback and enable the SSPR service to detect the cloud sync agent, you need to use the Set-AADCloudSyncPasswordWritebackConfiguration cmdlet and tenant’s global administrator credentials:
Import-Module “C:\\Program Files\\Microsoft Azure AD Connect Provisioning Agent\\Microsoft.CloudSync.Powershell.dll”
Set-AADCloudSyncPasswordWritebackConfiguration -Enable $true -Credential $(Get-Credential)
Configure Cloud Sync
The next step will guide you through configuring Azure AD Connect Cloud Sync.
Scope provisioning to specific users and groups on the agent to synchronize specific users and groups using on-premises Active Directory groups or organizational units. You can’t configure groups and organizational units within a configuration.
Attribute Mapping allows you to easily map attributes between your on-premises user/group objects and the objects in Azure AD. You can customize the default attribute mappings according to your business needs.
TIP: On-demand provisioning allows you to test configuration changes by applying these changes to a single user or group. You can use this to validate and verify that the changes made to the configuration were applied properly and are being correctly synchronized to Azure AD.
Accidental Deletions are designed to protect you from accidental configuration changes and changes to your on-premises directory that affect many users and groups.
TIP: Quarantines – Cloud sync monitors the health of your configuration and places unhealthy objects in a quarantine state.
Single Sign-on – Currently, there is no option to enable SSO when the agent is installed. However, you can use the steps below to enable SSO and use it.
- Download the latest version of Azure AD Connect and Azure AD PowerShell
- Open a command prompt using Administrative privileges and navigate to the MSI you just downloaded.
- Run the following:
msiexec /a C:\filepath\AzureADConnect.msi /qb TARGETDIR=C:\filepath\extractfolder
- Then, browse to the
%programfiles%\Microsoft Azure Active Directory Connectfolder.
- Import the Seamless SSO PowerShell module by using this command:
- Run PowerShell as an administrator. In PowerShell, call
New-AzureADSSOAuthenticationContext. When prompted, enter your tenant’s global administrator credentials.
Get-AzureADSSOStatus. This command provides you with the list of Active Directory forests (look at the “Domains” list) on which this feature has been enabled.
Enable-AzureADSSOForest. Enter the domain administrator credentials for the intended Active Directory forest when prompted.
A short summarize. It seems that Microsoft did a lot with the Cloud Sync approach, but still, there is a lot to be done because the Cloud Sync needs to be with all features inside without the requirements to run PowerShell for specific settings such ah enabling SSO. Of course, this is still in preview. Hence, it will improve by the time and before the GA.