Ten things you should know about Azure AD Connect and Azure AD Sync

Azure Active DirectoryAzure 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, 2015.

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:

  1. AlwaysOn Failover Cluster Instances
  2. AlwaysOn Availability Groups
  3. Database mirroring
  4. 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.

Configure Staging Mode in Azure AD Connect (click for original screenshot)

 

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:

    • SERVERNAME\AAD_<GUID>
      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.
    • DOMAIN\MSOL_<GUID>
    • 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.

Sync_SERVERNAME_<GUID>@tenant.onmicrosoft.com

    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:

  1. Microsoft System Center Operations Manager (OpsMgr)
  2. Microsoft Operations Management Suite (OMS)
  3. 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.

Note:
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.

 

Related blogposts

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

Further reading

How To Run Manual DirSync / Azure Active Directory Sync Updates
AAD Sync installation failure when using external SQL Server
Custom installation of Azure AD Connect
DirSync Accounts

6 Responses to Ten things you should know about Azure AD Connect and Azure AD Sync

  1.  

    You mention the Global admin account but I would also mention that Azure AD Connect requires Enterprise Admin.

    • Azure AD Connect requires an Enterprise Admin account in multi-forest and multi-domain environments. Where a Domain Admin would be able to create the necessary (service) accounts and user rights in a single domain environment, in multi-forest and multi-domain environments, an account with membership to the Enterprise admins group is required.

      One big difference between the Global Administrator in Azure AD account requirement for Azure AD Connect and the Enterprise Admin in the on-premises Windows Server Active Directory requirement is that Microsoft actively communicates to make the first account an account without password expiration and without Multi-Factor Authentication (MFA) (since Azure AD Connect does not, currently, support MFA). Microsoft does not actively communicates these practices for the latter account.

      One of the big problems I thought customers might have with an Enterprise Admin account is that it would be used for an interactive logon. With corporate policies restricting these types of logons on systems to avoid lateral movement and privilege escalation, as well as Windows Server 2012 R2’s Authentication Policies (restricting Enterprise admins purely to Domain Controllers, for instance), this might have been a real issue. However, Azure AD Connect asks for the credentials every time it is started and does not store or cache the credentials of the Enterprise admin account.

       
  2.  

    Hello. I’m a MS Partner and I write implementation docs on technologies such as this, in a way that small businesses can easily understand them. This is for companies that generally do not have full-time IT staff. Do you think there is a place for this with clients/customers that have <50 seats and have a very simple environment (1-2 servers, 1 location, using Office 365, etc.)? I'm having a hard time understanding the real value of this software for those situations. Perhaps I'm missing something.

    • Hi Ryan,

      Thanks for your reply.

      The above information is now almost six months old, and a lot has happened in this space.
      While not all points have been adressed (strictly speaking merely points 7 and 8 have), most of these don’t affect the designs you write for the organizations with the size you describe.

      Azure AD Connect, either with or without AD FS, offers object synchronization and, as such, offer hybrid identity.
      Without hybrid identity, Office 365 would needlesly offer an awful user experience and admins would have a tough time controlling access to their organizations data both on-premises and ‘in the cloud’: Yet another username/password combination would be the vocal feedback from both employees and admins.

      With 1 or 2 servers, the organizations you speak of ,fall in one of two categories:
      1. They don’t have redundant Domain Controllers, or
      2. All servers are Domain Controllers.

      Luckily, Azure AD Connect can be installed on Domain Controllers and, in that case, can be used with ‘Express Settings’, offering automatic upgrades and automatic scheduling of syncs. In environments with these kinds of IT environments, mostly, security and availability are not top priorities. Most of the points above, in that case, don’t apply. The ‘Express Settings’ won’t give you a hard time (‘tyranny of the default’), yet offer the advantages of hybrid identity to end users and the level of control and unambiguity to admins. Since the Domain Controllers will likely already be misused for other purposes, adding Azure AD Connect won’t add an awful lot of complexity to disaster recovery: You had to restore the entire box, already.

       
  3.  

    Is it mandatory to sync passwords to Azure AD? Can I have a null/no value for password field in AD? How to set this up? Also, on a side note, is it possible to authenticate users with on-premise directory without having an ADFS?

    • Hi Surya,

      It is not mandatory to synchronize passwords to Azure AD, but then you will need to implement an alternative authentication method. AD FS is the most common authentication method, but other federation solutions will also work, of course.

      Last week, at Ignite, a new feature was announced for Azure AD Connect, labeled ‘Passthrough Authentication’. This feature might also prove to become a valid alternative authentication method, by redirecting authentication traffic to on-premises Domain Controllers but without federation of any kind.

       

leave your comment