How to audit the Entra Connect sync account: Find every sync identity, check its rights, watch its sign-ins

The Entra Connect sync accounts can read every password hash in Active Directory and write to every synced object in Entra ID, yet most tenants have never checked how many exist, what rights they hold or where they sign in from. This runbook audits all of them: the AD DS Connector account on premises, the ADSync service account on the sync server, and the cloud identity that writes to Entra ID, whether that is a legacy user in the Directory Synchronization Accounts role or the newer application identity with a certificate. It starts with read-only discovery, then permission and sign-in checks, then changes with a rollback for each. It is for identity engineers and Tier 0 administrators running hybrid tenants with Entra Connect Sync. For the wider hardening baseline, see the Microsoft Entra Connect and Cloud Sync Hardening Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features and cmdlets change, so confirm each step against Microsoft's current documentation before you run it.

Key takeaways

• There are three sync identities, not one. The AD DS Connector account (MSOL_ prefix with express settings), the ADSync service account (AAD_ prefix when the wizard creates it) and the Entra Connector identity each need their own checks.
• Count the cloud sync accounts first. List members of the Directory Synchronization Accounts role (template ID d29b2b05-8046-44ba-8758-1e26182fcf32). Entra ID allows at most 20, and accounts from rebuilt or staging servers linger.
• Read the AD permissions, do not assume them. Get-ADSyncADConnectorAccount names the connector account and Show-ADSyncADObjectPermissions lists the rights on any object, so you can compare what is granted with the features you actually use.
• Sign-ins should come from one place. A sync identity signing in from any IP address other than the sync servers is an incident until proven otherwise. Storm-0501 used stolen sync credentials to reach Microsoft Graph.
• Move to application-based authentication, then remove the old user. From Entra Connect 2.5.3.0 the cloud side can use a certificate-bound application; Microsoft strongly recommends removing the legacy account afterwards with Remove-ADSyncAADServiceAccount.

When you need this

• Before and after an Entra Connect upgrade or server rebuild: each installation and each staging server creates its own cloud connector account, so rebuilds leave orphans.
• After an on-premises compromise: whoever controls the sync server can recover the sync credentials. Treat the sync accounts as exposed whenever a Tier 0 system is.
• When moving to application-based authentication: the audit tells you which legacy accounts to remove and gives you a baseline of normal sign-in behaviour.
• On a fixed cycle: quarterly is our suggestion, in line with the review of other Tier 0 identities. See the Tiered Administration and Enterprise Access Model Guide.

Before you start

The three identities you are auditing

The password hash sync rights are the same rights abused in DCSync (ATT&CK T1003.006), so anyone holding the connector account's credentials can pull every hash in the domain. See the Golden Ticket, Silver Ticket and DCSync Guide.

Step-by-step

1. List every cloud sync account

Microsoft documents this query to find members of the role:

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$directoryRoleId = Get-MgDirectoryRole | where {$_.DisplayName -eq "Directory Synchronization Accounts"}
Get-MgDirectoryRoleMember -DirectoryRoleId $directoryRoleId.Id |
  Select-Object Id,@{Name="UserPrincipalName"; Expression={$_.AdditionalProperties.userPrincipalName}}

For each account record the server name embedded in the user name, whether that server still exists, whether it is the active or a staging server, and the account's last sign-in. The Entra admin center shows these accounts with the plain User role, so a portal search by role misses them; use the query. Any account whose server is gone is a removal candidate in step 7.

2. Confirm how the active server authenticates to Entra ID

On the sync server run Get-ADSyncEntraConnectorCredential and read ConnectorIdentityType: ServiceAccount means the legacy user and password, otherwise the server uses an application. The wizard shows the same under Tasks, View or export current configuration, including the application (client) ID, who manages the certificate, whether automatic rotation is on, the thumbprint, validity dates and the key storage provider. Microsoft Platform Crypto Provider means the key is in a TPM; Microsoft Software Key Storage Provider means it is not.

Run Get-ADSyncScheduler too. Automatic certificate rotation only happens while the scheduler runs, so a suspended scheduler means a certificate heading for expiry.

3. Identify the AD DS Connector account and read its permissions

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
Get-ADSyncADConnectorAccount
Show-ADSyncADObjectPermissions -ADobjectDN 'DC=contoso,DC=com'

Run Show-ADSyncADObjectPermissions against each domain root and against any OU where inheritance is blocked (Get-ADSyncObjectsWithInheritanceDisabled -SearchBase <DN> finds them). Then compare the result with the features you have enabled:

Also check the account's own object. Since build 1.4 the wizard rejects Enterprise Admin and Domain Admin accounts, but older installs and hand-built accounts may still be members of privileged groups. Check memberOf, adminCount, password age and whether the account is protected by Set-ADSyncRestrictedPermissions, which disables inheritance on the account and leaves only SYSTEM, Enterprise Admins, Domain Admins, Administrators, and read for Enterprise Domain Controllers and Authenticated Users. If a Tier 1 group can reset this account's password, that group effectively holds DCSync.

4. Check who controls the sync server

The sync server stores the connector credentials encrypted, and anyone with local administrator rights there can recover them. Storm-0501 did exactly this. List the local Administrators group and ADSyncAdmins, and treat each member as Tier 0. Check that the server has EDR in block mode with tamper protection, which Microsoft recommends after Storm-0501, and that the local administrator password is managed by Windows LAPS. See the LAPS Guide.

5. Baseline where the sync identities sign in

Sync accounts should authenticate only from the public egress addresses of your sync servers. Using the user principal names from step 1:

let syncUpns = dynamic(["[email protected]"]);
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName in~ (syncUpns)
| summarize SignIns = count(), Apps = make_set(AppDisplayName, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by UserPrincipalName, IPAddress, ResultType
| order by UserPrincipalName, SignIns desc

For application-based authentication, query AADServicePrincipalSignInLogs on the application ID from step 2 the same way. Anything from an unexpected IP address, or any application other than the sync service, needs investigation. Microsoft's Storm-0501 guidance names Defender detections to watch for, including "Suspicious sign-in to Microsoft Entra Connect Sync account" and "Entra Connect Sync credentials extraction attempt".

6. Check the on-premises side of the connector account

• Logons: event 4624 for the MSOL_ account from any computer other than the sync server.
• Replication: event 4662 on domain controllers with the replication control access rights 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Replicate Directory Changes) and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Replicate Directory Changes All). From the sync server under the connector account this is normal; from anywhere else it is DCSync.
• Interactive logon: the account should be denied interactive and remote desktop logon through Group Policy, so any 4624 with logon type 2 or 10 is an alert.

7. Remove orphaned and legacy cloud accounts

For accounts from servers that no longer exist, Microsoft documents Remove-MgUser -UserId <Id>. Do not remove the account the active or staging server currently uses; match the server name from step 1 to the live inventory first.

Where the active server already uses application-based authentication and sync has run cleanly, remove the legacy account from the sync server:

$HACredential = Get-Credential
Remove-ADSyncAADServiceAccount -AADCredential $HACredential -Name <Sync_Server_id>

The name is the first part of the user principal name. If the account cannot be removed, Microsoft says to deprivilege it and remove its Directory Synchronization Accounts role.

8. Restrict sign-in for whatever remains

After Storm-0501, Microsoft recommended a Conditional Access policy that limits sync accounts, identified by the Directory Synchronization Accounts role, to trusted IP addresses. Create it in report-only mode, confirm from step 5 data that every sync sign-in comes from a named location, then enforce. Microsoft has also restricted the permissions of the Directory Synchronization Accounts role itself, but that does not make a stolen credential harmless. See the Conditional Access Guide.

9. Watch the application credential

With application-based authentication, the risk moves to whoever can add a credential to the sync application. Microsoft warns that the Application Administrator role can add credentials to the Connect Sync application and impersonate it, an elevation of privilege. Cloud Application Administrator can also manage application credentials, so we suggest treating it the same way. Alert in AuditLogs on certificate and secret changes to that application where the initiator is anyone other than the sync server, and treat holders of those two roles as Tier 0 in hybrid tenants. On the server, the Application event log records event 1011 when the certificate has used 70% of its lifetime, 1012 when it has expired and 1014 when no TPM is used.

Verify it worked

• The step 1 query returns only the accounts for current servers, or none if every server uses application-based authentication.
• Get-ADSyncEntraConnectorCredential shows the expected identity type on the active and staging servers, and the next sync cycle completes without errors in Synchronization Service Manager.
• Show-ADSyncADObjectPermissions output matches the feature table, with no replication rights where password hash sync is off.
• Report-only results for the sync account location policy show no sign-ins that would have been blocked over at least one full week.
• No 4662 replication events for the connector account from hosts other than the sync server.

Rollback and common errors

Common failure patterns

• Treating the sync server as a member server. Tier 1 administrators and backup agents with local admin there can recover the connector credentials. In the Storm-0501 hybrid cloud attacks, the actor extracted the on-premises and cloud sync credentials from the server and used the cloud one to get a Microsoft Graph token.
• Granting every permission "in case". Express settings grant replication and broad write rights; organisations that never use writeback or Exchange hybrid keep them for years.
• Orphaned cloud sync accounts. Each rebuild adds another password-based account with a role that cannot be granted outside the wizard, so nobody thinks to remove it.
• No sign-in baseline. Without one, a sync account signing in from a residential IP address looks like any other non-interactive sign-in.
• Moving to application authentication but leaving Application Administrator broad. The credential risk moves from a password to whoever can add a certificate.

Metrics and mapping

Where identity fits: the sync accounts are non-human identities with Tier 0 reach. Give them a named owner, record them in your NHI inventory and review them with the other service accounts. See the Service Account Security Guide.

Practitioner checklist

• Export Directory Synchronization Accounts role members and map each to a live server.
• Record the authentication type, certificate details and scheduler state on every sync server.
• Run Show-ADSyncADObjectPermissions on each domain root and blocked-inheritance OU.
• Remove AD rights for features that are not enabled, starting with replication rights.
• Limit local administrators and ADSyncAdmins on the sync server to Tier 0.
• Baseline sync identity sign-ins and alert on any new IP address or application.
• Alert on 4662 replication requests from anything other than the sync server.
• Migrate to application-based authentication and remove legacy accounts.
• Enforce a location-restricted Conditional Access policy for the sync role.
• Alert on credential changes to the sync application and review who can make them.

Standards and references

• Microsoft Learn: Microsoft Entra Connect accounts and permissions
• Microsoft Learn: Configure AD DS Connector account permissions
• Microsoft Learn: Authenticate to Microsoft Entra ID by using application identity
• Microsoft Learn: Microsoft Entra built-in roles
• Microsoft Threat Intelligence: Storm-0501 ransomware attacks expanding to hybrid cloud environments
• MITRE ATT&CK: T1003.006 OS Credential Dumping: DCSync
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Microsoft Entra Connect and Cloud Sync Hardening Guide · Active Directory and Entra ID Hardening Guide · Golden Ticket, Silver Ticket and DCSync Guide · How to Find guest users with privileged roles in entra id