Azure Active Directory powers Microsoft Online Services, ranging from Office 365 to Intune, in terms of identity. While this compels to organizations in a strong way, Microsoft even offers hybrid identity options to organizations running on-premises Windows Server Active Directory to stretch their identity layer to the cloud.
The tool from Microsoft to support its latest hybrid identity scenarios is Azure AD Connect. Azure AD Connect became generally available on June 24, 2015. Azure AD Sync became generally available on September 16, 2014.
I’ve been designing, implementing and managing Azure AD Connect and Azure AD Sync for several organizations since this time. It has become one of my favorite tools in my toolbox, but there are a couple of things that I think you should know:
1. Azure AD Connect and Azure AD Sync are not High Available
If you want to make Azure AD Sync highly available, then you’re pretty much out of luck; Azure AD Connect and Azure AD Sync do not support Failover Clustering or automatic failover. It is only supported to have one installation of Azure AD Sync connected to one directory in the Azure Active Directory.
Azure AD Connect does support multiple Azure AD Sync installations, but only one may be actively synchronizing with Azure Active Directory. Any additional Azure AD Sync installation should be configured in Staging Mode. In Staging Mode the sync engine will import and synchronize data as normal, but it will not export anything to Azure Active Directory or the on-premises Windows Server Active Directory. Password sync and password write-back are disabled.
At best, this offers a fall-back scenario for the Directory Synchronization functionality.
2. Azure AD Sync only supports SQL Clustering
You can choose to have Azure AD Connect and Azure AD Sync to use a dedicated SQL Server installation as its synchronization database host, instead of the default local SQL Server 2012 Express installation.
SQL Server offers High Availability. SQL Server supports four High Availability (HA) scenarios:
- AlwaysOn Failover Cluster Instances
- AlwaysOn Availability Groups
- Database mirroring
- Log shipping
The only SQL Server High Availability (HA) scenario supported is AlwaysOn Failover Cluster Instances (SQL Server). If you have a dedicated or centralized SQL Server infrastructure that you want to use as the database server infrastructure for your SQL workloads and for Azure AD Sync, make sure it is an AlwaysOn Failover Cluster.
3. Staging Mode does not sync settings
Since Staging Mode offers no shared configuration, there is no automated way to keep all specific settings in sync between Azure AD Sync installations. Changes to the Azure AD Sync configuration in fall-back implementations should be kept up to date on both hosts for reliable fall-back. This pertains to settings like filtering settings, settings to synchronize additional directory extensions, although other settings may be stored in the Azure Active Directory.
4. Azure AD Sync does not use (g)MSAs as its service accounts
While Active Directory Federation Services (AD FS) in Windows Server 2012 R2 is capable of running its service using a group Managed Service Account (gMSA), Azure AD Sync is not capable of using such an account to connect to your on-premises Windows Server Active Directory environment(s).
From a security point of view, Azure AD Sync poses a security risk with the service account it uses to connect to your on-premises Windows Server Active Directory environment(s).
By default, Azure AD Sync creates service accounts with minimal privileges but with non-expiring passwords on the Windows Server running Azure AD Sync, and in both the on-premises Windows Server Active Directory and the Azure Active Directory tenant:
This account is configured as a local account on the Windows Server running Azure AD Sync to run the Microsoft Azure AD Sync service and scheduled task for DirectorySyncClientCmd.exe. It has Allow log on locally, Log on as a batch job and Log on as a service user rights assigned on the server in the local security policy.
- This account is configured as a member of the Domain Users group in the on-premises Active Directory environment your Azure AD Sync installation is a member of. It has additional delegated rights, depending on the password write-back settings.
- This account is configured with the user role in the tenant’s Azure Active Directory.
While the latter account cannot be configured as a (group) Managed Service Account, the first two accounts make sense as MSAs or gMSAs.
In highly secure environment, your choices may be to create service accounts with non-expiring password of their knowledge, instead. Be aware, though, that the password of the local service account (as the password for the automatically created service account) is stored in the registry of the Windows installation running Azure AD Sync.
5. Azure AD Connect requires a Global Admin account in Azure AD
To connect with the organization’s Azure Active Directory tenant, Azure AD Connect and Azure AD Sync require an account in Azure Active Directory with the Global Administrator role assigned to it.
Microsoft recommends to configure this account with the default tenant.onmicrosoft.com UPN suffix, a non-expiring password and without Multi-Factor Authentication (MFA). When the password expires for the account in Azure Active Directory, Azure AD Connect breaks.
From a security point of view, this, again, raises concerns. In highly secure environments you might want to have procedures to change the password for the Azure AD account people use when they change settings in Azure AD Connect.
6. Azure AD Sync stores its synchronization database on the system volume, by default
Azure AD Connect places its synchronization database in C:\Program Files\Microsoft Azure AD Sync, by default.
It is a best practice to not place dynamic data on system volumes. Yet, here we are. If you want to use a SQL Server with Azure AD Sync, you will need to run directorysynctool.exe with the /sqlserver command line switch.
7. In some situations, Azure AD Connect offers little to no information in the Event logs
While managing several Azure AD Connect installations, and occasionally troubleshooting errors, it really bugs me, that Azure AD Connect provides so little information in the Event logs.
For instance, I have seen an Azure AD Connect lose its connection to Azure Active Directory in a way that synchronization from Windows Server Active Directory on-premises to Azure Active Directory would still work, but password changes and passwords resets from Azure Active Directory back to Windows Server Active Directory on-premises wouldn’t anymore. Not a trace in the Event logs…
Applying the oldest trick in the Citrix books to just restart the Windows Server running Azure AD Connect daily at 3AM, is something nobody should have to.
8. Azure AD Connect can’t be sufficiently monitored using Microsoft solutions
Microsoft offers three solutions for monitoring your environment:
- Microsoft System Center Operations Manager (OpsMgr)
- Microsoft Operations Management Suite (OMS)
- Microsoft Azure AD Connect Health
These three solutions can be used to monitor your AD FS Implementation (and beyond with the first two), none of these solutions are able to monitor Azure AD Sync.
Monitoring the Azure AD Sync implementation has been announced for Azure AD Connect Health.
Now, in the situations mentioned above, where there’s little to no information in the event log, I’m hoping they’ll get things right, based on trend analysis. (“Normally, three people on average change their passwords, but today no-one did. Perhaps something is wrong.”)
9. Azure AD Sync includes only one sync engine
Azure AD Sync comes with one sync engine. When it breaks, Azure AD Sync breaks. When it partially breaks, as in the situation above, it remains partially broken until you restart synchronization.
10. Azure AD Connect and Azure AD Sync rely heavily on SSL/TLS
Azure AD Connect and Azure AD Sync communicate with Azure AD using TCP 443. SSL/TLS is used heavily to encrypt the data that is exchanged between the Azure AD Sync installation and Azure Active Directory.
However, certificate-based encryption, and specifically their fall-back methods for negotiating the protocol and encryption strength to use, have been targeted in attacks in recent years. In my opinion, SSL/TLS is not a real security layer anymore.
Five Things you should know about using DirSync with Password Sync
Azure Active Directory Synchronization: An Introduction, Part 1
Azure Active Directory Synchronization: An Introduction, Part 2
Azure Active Directory Synchronization: Filtering, Part 1
Azure Active Directory Synchronization: Filtering, Part 2
Azure Active Directory Synchronization: Object Matching