Entra Connect application authentication retires the old sync password

In hybrid identity environments, few things have caused me as much trouble as the old Directory Synchronization Account. Entra Connect (formerly Azure AD Connect) creates this privileged service account, complete with a password, to sync users to the cloud. I still come across plenty of tenants running this legacy sync user, sometimes with weak credentials or even cleartext passwords sitting in some forgotten corner. Since 2022, a series of incidents has shown attackers going after these accounts for lateral movement and persistence. Newer versions of Entra Connect Sync therefore support application authentication. The sync server authenticates to Entra ID as an application with a certificate, not as a user account with a password.

Entra Connect application authentication removes a favourite attacker target

For hybrid identity security, this change makes a real difference. The classic sync account was a prime target and an easy way in, because one compromised password gave broad privileges. Application authentication takes that risk away, since the sync service principal signs in with a certificate instead of a password. Microsoft describes the details in Application authentication in Entra Connect on MS Learn. In the field the effect is easy to see. There are fewer exposed credentials, no more legacy accounts with passwords nobody has rotated, and auditing gets better. Certificates still need protection, of course, but their lifecycle and exposure are much easier to control.

The following diagram shows the old and new authentication paths the way I see them in practice:

flowchart TD
    AD["On-Prem AD"] --> EntraConnect["Entra Connect Server"]
    EntraConnect -- "User/Pass (old)" --> SyncAccount["Directory Sync Account"]
    EntraConnect -- "App+Certificate (new)" --> AppObject["App Registration"]
    SyncAccount -- "PasswordAuth" --> EntraID["Entra ID"]
    AppObject -- "CertificateAuth" --> EntraID

Figure: Classic password authentication compared with application authentication in Entra Connect.

In regulated or larger environments this is a big step. Besides better security, application authentication gives you a cleaner operational lifecycle. Manual password rotation goes away, deployments are easier to automate, and depending on your policies you can back the certificates with HSMs or other hardware protection. You can also scope the service principal's permissions more tightly than those of a typical user account, which always felt like a workaround before.

Application authentication requires a current Entra Connect Sync version

Not every version of Entra Connect Sync supports application authentication. If you're still on an older release, check for an update now. According to the current announcement, application authentication is the default for new installs and is enforced for full redeployments. The list of supported builds can change, so check compatibility and release status regularly in the official version history.

A quick look in the Entra admin center under Entra Connect → Connect Sync shows the current version and the authentication type in use. After switching to application authentication, I always recommend searching for legacy sync accounts in both on-prem AD and Entra ID and cleaning them up. If you want to harden the server itself, my earlier post covers that: what the Storm-0501 attacks taught me about securing the Entra Connect server.

Auto-upgrade does not replace regular lifecycle checks

Many admins underestimate how important it is to keep Entra Connect Sync current. Auto-upgrade helps, but it isn't always available or enabled, particularly in complex or customised environments. In my experience you still end up patching manually more often than not. An outdated sync server is a security risk, and as authentication models change it also turns into a support problem. Review the auto-upgrade settings and the server's update log (in the Entra Connect management console) every so often so you don't fall behind.

Practical tip: After every major Entra Connect update or redeployment, verify that application authentication is really in use. I've seen old sync accounts survive for years after an upgrade because nobody checked the switch.

The sync server still needs Tier 0 protection

Even without the old sync account, the Entra Connect server remains Tier 0. An attacker who compromises it can manipulate your identities or disrupt sync. So it belongs in your most tightly monitored and protected network segment. That means no extra server roles, a firewall in front of it, a hardened configuration, only the management tools you actually need, and remote access locked down. Application authentication helps a lot, but you still need a solid Tier 0 security model.

A short PowerShell query finds legacy sync accounts in AD

To look for leftover classic sync users in Active Directory (they're usually named “MSOL_”), run the following PowerShell on a domain controller or a machine with RSAT:

Get-ADUser -Filter { Name -like "MSOL_*" } | Select-Object Name, Enabled, LastLogonDate

The output makes it easy to spot unused legacy accounts and remove them.

I see no reason to keep old sync accounts any longer

Far too often, Entra Connect ends up as a box in the corner that someone set up once and then forgot. Yet authentication for directory sync sits at the core of your hybrid identity security. Keeping old accounts and outdated versions around practically invites attackers in. Moving to Entra Connect application authentication isn't optional, and any serious hybrid identity setup needs it. With the tools now available in the admin center, I don't see a good reason to put this upgrade off.