Stop Treating Entra Connect Like Middleware

Entra Connect is well known as the application responsible for synchronizing on-premises Active Directory (AD) identities to the Entra Cloud. This service is not only integral to an environment’s operational health, it must be on your security radar as it straddles two trust boundaries and is the authority for your hybrid identities.

All too commonly, Entra Connect is deployed just like an ordinary application rather than being treated as the Tier 0 asset it is. If you run Entra Connect, treat it as Tier 0 infrastructure: isolate the server, restrict the connector accounts, exclude privileged identities from sync, and retire Seamless SSO unless there is a clear business reason to keep it.

Treat Entra Connect as Tier 0 infrastructure

Yes, I still like to use the Tier 0 terminology over the Enterprise Access Model (EAM) or Red Forest because it’s simpler to understand. They’re all built on the fundamental theory of allowing only privileged assets to communicate with other privileged assets.

As it relates to Entra Connect, this means two things.

1. The server object must be in a protected Organizational Unit (OU) where only Tier 0 admins hold local admin, Group Policy Object (GPO) rights, or access control lists (ACL) on upstream objects.
2. It’s important to scrutinize the installed software and infrastructure as anyone with access to Configuration Manager (SCCM), the hypervisor, or backup disks may break the Tier 0 control plane.

However, Entra Connect is more than simply the server it’s running on. There are a series of identities involved in the synchronization process.

The connector accounts define the real blast radius

The security question is not just whether these accounts exist, but what each one can change if the Entra Connect server or its credentials are compromised.

AD DS Connector Account

The AD DS Connector Account, typically named with the MSOL prefix, is the AD side of Entra Connect. Upon deployment, this account is delegated highly privileged access inside of AD and therefore must receive the Tier 0 treatment. A common misconfiguration of the AD DS Connector Account is that it’s also delegated permissions via the AdminSDHolder template, giving it control over your most privileged objects such as Domain Admins.

Removing permissions on the AdminSDHolder template limits the blast radius of a compromised AD DS Connector Account but it doesn’t prevent synchronization of those admin accounts.

The second half of this configuration is the sync scope. OU or group filtering should be excluding all Tier 0 and even Tier 1 admins from synchronization. These steps are important to protect against a number of known attack techniques where an on-premises compromise turns into a cloud compromise, or vise-versa.  

Entra Connector Account

The Entra Connector Account, named with the Sync prefix, is the Entra side of Entra Connect. Permissions on this side of the synchronization has undergone several hardening updates over the last few years but due to the nature of its use, this identity must maintain privileges that still make it vulnerable.

In a July 2025 update, an application identity replaced the user identity. Entra Connect version 2.5.76 and newer default to use the new identity type. New versions are consistently being released that address security issues so it’s important to keep the Entra Connect version updated.

A staging server only helps if you harden it like production

What’s better than an up-to-date Entra Connect server? Two Entra Connect servers! Establishing resilience by setting up a secondary server in staging mode serves as a warm backup. The servers must be on matching Entra Connect versions to avoid sync-rule incompatibility on failover. Each server holds its own copy of equally sensitive credentials, so all previous hardening recommendations also apply to a secondary server.

Seamless SSO is legacy risk most tenants should retire

In most cases, modern operating systems and Entra/hybrid-joined devices now use a Primary Refresh Token (PRT) that replaces the need for the Seamless SSO service. Seamless SSO depends on a shared Kerberos decryption key stored on the AZUREADSSOACC computer account in AD. If an attacker extracts that key, they can forge tickets and impersonate any synced user. Microsoft’s only mitigation for Seamless SSO is a manual key roll every 30 days that has no automation and is easily forgotten.

Hybrid identity security starts with Tier 0 discipline

Attacks on hybrid identities continue to work because the Entra Connect server was never treated as privileged, legacy defaults continue to exist from initial install, and consistent Tier 0 discipline is not implemented.

If you only make one change, stop treating Entra Connect like middleware. Put the server, its connector accounts, its backup path, and its staging instance inside your Tier 0 control plane. Then turn off Seamless SSO unless you can prove it is still required and actively maintained. This is in no way an exhaustive hardening advice but it sure is a good start toward a security-focused approach to keeping attackers at bay.