When you read through Azure AD Connect’s prerequisites page, you’ll notice that Microsoft supports installing Azure AD Connect on Active Directory Domain Controllers.
While this would certainly be a helpful scenario for organizations with up to 50 user accounts, I would not recommend doing so.
Installing Azure AD Connect on a Read-only Domain Controller is a no-go area.
Is the problem with Active Directory or with Azure AD Connect?
Requiring a reboot for Azure AD Connect might result in temporal denial of service to users, applications, systems and/or services that rely on the Active Directory Domain Controller. This is especially true for environments with a single Domain Controller. I know this scenario is unsupported, but common in small environments.
In terms of disaster recovery (DR), it’s a best practice to keep all Active Directory Domain Controllers as similar as possible and to configure them identically, following a pre-approved procedure. This way, when a Domain Controller fails, it can easily be rebuilt from scratch. When you install Azure AD Connect on an Active Directory Domain Controller, it becomes a one-off.
Azure AD Connect comes with a SQL Server 2012 Express Edition database. When you install SQL Server on an Active Directory Domain Controller, you lose the ability to demote the Domain Controller. This might hurt any disaster recovery procedure you might want to follow, when, for instance, the Active Directory database (ntds.dit) becomes corrupted.
In the worst case scenario, the Active Directory Domain Controller functionality and the Azure AD Connect functionality, would both have to be rebuilt from scratch. I wonder how many people have documented and/or exported their Azure AD Connect configuration, and especially their custom synchronization rules…
Any application and/or agent installed on an Active Directory Domain Controller adds attack surface. Azure AD Connect and especially its SQL Server 2012 Express Edition may contain vulnerabilities, that would lower the security stance of the Active Directory Domain Controller they are installed on.
Any Azure AD Connect service accounts that need admin to the local server are added to the Builtin\Administrators group in Active Directory and, thus, gain administrative privileges to the Active Directory domain.
Azure AD Connect comes with SQL Server Express, when you don’t choose to use a separate SQL Server (cluster) to host its database. SQL Server uses resources and is particularly fond of RAM. Active Directory Domain Controllers also likes to use your RAM, to cache its database (ntds.dit).
Granted, in small organizations, the Active Directory database (ntds.dit) would not exceed 40MB, but in some larger organizations, both RAM usages would collide and starve the Windows Server installation from available RAM. Performance issues might follow, when the disk subsystem is hammered for the pagefile.
Global Catalogs and the PDC Emulator
When you install any application on an Active Directory Domain Controller, it tends to communicate exclusively to that Domain Controllers. Surely, the Domain Controller wouldn’t need other Domain Controllers to provide the right information. All Domain Controllers are created equally anyway, right?
Some Active Directory Domain Controllers are created more equally than others. Some Domain Controllers act as Global Catalogs. In an environment with multiple Active Directory domains and/or multiple Active Directory forests, Azure AD Connect should be installed on a Global Catalog.
When you promote a Domain Controller to a Global Catalog, don’t forget to reboot it afterwards.
Other Active Directory Domain Controllers hold one or more of the Flexible Single Master Operations (FSMO) roles. Ranging from forest-wide to domain-wide roles, one role is of particular importance: the PDC Emulator role. The Domain Controller with the PDC Emulator Role in each Active Directory domain is the source of replication for password(hashe)s and Group Policy changes. If you really need to install Azure AD Connect on a Domain Controller, especially when using Password Hash Sync (PHS), installing Azure AD Connect on the Domain Controller with the PDC Emulator FSMO Role would make the most sense for the scenario.
Microsoft KnowledgeBase Article 2032911 states that is not recommended to install SQL Server on an Active Directory Domain Controller and explains that you ‘may encounter problems’.
From a support point of view, this means that when you encounter problems, you might need to relocate Azure AD Connect somewhere else on the network, before Microsoft would start troubleshooting your issues.
Don’t do it.