The Entra Connect Sync first-party app in Conditional Access and sign-in logs

Oct 01, 2025 · Samantha Kloos-Kilkens

On Entra Connect Sync 2.5.76.0 and later, a server that still signs in with the old connector user account switches itself to an application with a certificate, and the resource that application requests tokens for is a Microsoft first-party service principal called Microsoft Entra AD Synchronization Service (app ID 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016). That changes which Conditional Access policies apply to your sync, who can impersonate it and where its sign-ins end up. At the end of September Microsoft also turned it into a deadline: every Connect server has to run 2.5.79.0 or later by 30 September 2026. This post covers what the app is, how both sync identities relate to Conditional Access, how to monitor them and how to check per server which version and which identity it uses.

Electricity pylons with glowing power lines at sunset Photo: Getty Images on Unsplash

What the Microsoft Entra AD Synchronization Service is

Microsoft first listed the app in the December 2024 release notes (now in the What's new archive) as a dedicated first-party application for synchronization between Active Directory and Microsoft Entra ID, provisioned in tenants that use Connect Sync or Cloud Sync. You'll find it under Enterprise applications if you search on the app ID with the application type filter set to Microsoft applications. The more useful description is on the Learn page Authenticate to Microsoft Entra ID by using application identity. In its Bring Your Own Application section the app shows up as the resource: the Connect application needs the app role ADSynchronization.ReadWrite.All on Microsoft Entra AD Synchronization Service (same app ID in every cloud), plus three PasswordWriteback app roles on the Microsoft password reset service if password writeback is enabled.

Application-based authentication became generally available, and the default, in version 2.5.76.0, released on 31 July with auto-upgrade from 14 August. From that version on, a server that authenticates with username and password is switched to application authentication automatically within six hours; manual onboarding works from 2.5.3.0. In the default mode Connect creates a single-tenant application in your tenant, stores its certificate in the TPM if there is one (otherwise in the software key storage provider, marked non-exportable) and rotates it itself. Version 2.5.79.0 followed on 1 September, with auto-upgrade in phases from 4 September, and its release notes are almost entirely about application authentication: a fallback when TPM signing fails, FIPS-enabled servers, and cleanup of certificates left behind by a failed setup.

So in many tenants the sync identity quietly changed this summer, from a user with a password to a service principal with a certificate. That change of identity is what most of this post is about, because it decides which of your policies apply to the sync.

Two sync identities and how Conditional Access sees them

Until a server is onboarded, it authenticates with the Microsoft Entra Connector account: a user with a long, non-expiring password and the Directory Synchronization Accounts role, one per server (staging servers included), with a limit of 20 per tenant. Microsoft's Conditional Access templates, such as Require MFA for all users, exclude these accounts through the directory role Directory Synchronization Accounts, and I'd check every All users policy for exactly that. An exclusion of one named account breaks the day a server is rebuilt and the wizard creates a new account. The same template recommends a baseline on All resources without app exclusions, so excluding the sync resource from that policy is the wrong way to keep sync working.

After onboarding, the server signs in as its single-tenant service principal with the client credentials flow. User-based policies don't apply to that sign-in. Conditional Access for workload identities does: it covers single-tenant service principals registered in your tenant, which is precisely what Connect creates. It needs Workload Identities Premium licenses, the only grant is Block, and the conditions are location and service principal risk. If you have a location policy for workload identities that includes the Connect application, either directly or because it includes all service principals in the tenant (ServicePrincipalsInMyTenant in Graph), the egress IP addresses of every Connect server must be in the allowed named location. Otherwise the token request is blocked and the sync cycle fails. Because onboarding happens automatically after an upgrade, including an auto-upgrade, this can happen outside any change window. The What If tool accepts single-tenant service principals, so you can test each Connect application before it starts signing in.
Diagram of the two ways an Entra Connect Sync server signs in to Microsoft Entra ID, as a connector user account or as a single-tenant application, with the Conditional Access policies that apply to each and the Microsoft Entra AD Synchronization Service resource they connect to.
On the resource side, policies that target All resources cover the new service principal automatically. Policies that select resources through filters for applications only match service principals that carry the right custom security attribute, and a service principal Microsoft provisioned for you carries none until someone assigns one. For the connector user account, I'd look at which resource its sign-ins actually hit before building any resource-based targeting or exclusion around it; the queries further down show that.

Who can act as your sync

The application identity page has a note worth reading twice: the Application Administrator role can add credentials to an application, "notably the Connect Sync", and use them to impersonate it, which Microsoft calls a possible elevation of privilege. The Connect application holds the permission the sync engine uses to write to Entra ID, so anyone who can manage its credentials belongs in the same tier as your Hybrid Identity Administrators. That includes Application Administrator, Cloud Application Administrator and any owner of the Connect application.

The usual application hardening levers don't map neatly onto this pair. App instance property lock, as Microsoft documents it, is something the owner of a multitenant application sets to lock credentials on its service principals in other tenants. You don't own the Microsoft resource, and Connect's application is single-tenant. "Assignment required" and the scripts that disable Microsoft service principals nobody recognises are a risk in the other direction: Microsoft describes this app as what enables synchronization, I haven't found documentation on how sync behaves with assignment required set on it, and I wouldn't want to find out in production. I'd exclude it explicitly from any such cleanup.

Once application authentication works, Microsoft recommends removing the legacy connector account with Remove-ADSyncAADServiceAccount, or, for a custom account that can't be removed, taking away its Directory Synchronization Accounts role. Connector accounts left behind by decommissioned servers are password-only identities with sync rights that your Conditional Access baseline excludes by design.

The script below lists the Microsoft resource, every principal holding an app role on it with the credential and owner situation of the matching application, and the remaining connector accounts.
Connect-MgGraph -Scopes "Application.Read.All", "RoleManagement.Read.Directory"

$syncSp = Get-MgServicePrincipal -Filter "appId eq '6bf85cfa-ac8a-4be5-b5de-425a0d0dc016'"
$syncSp | Select-Object DisplayName, Id, AccountEnabled, AppRoleAssignmentRequired

$roleNames = @{}
$syncSp.AppRoles | ForEach-Object { $roleNames[$_.Id] = $_.Value }

# Principals holding an app role on the sync resource (the Connect applications)
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $syncSp.Id -All |
    Where-Object PrincipalType -eq 'ServicePrincipal' |
    ForEach-Object {
        $sp  = Get-MgServicePrincipal -ServicePrincipalId $_.PrincipalId
        $app = Get-MgApplication -Filter "appId eq '$($sp.AppId)'"
        [pscustomobject]@{
            Principal     = $_.PrincipalDisplayName
            AppRole       = $roleNames[$_.AppRoleId]
            AssignedOn    = $_.CreatedDateTime
            AppCerts      = @($app.KeyCredentials).Count
            AppSecrets    = @($app.PasswordCredentials).Count
            SpCredentials = @($sp.KeyCredentials).Count + @($sp.PasswordCredentials).Count
            Owners        = if ($app) {
                                (Get-MgApplicationOwner -ApplicationId $app.Id |
                                    ForEach-Object { $_.AdditionalProperties.userPrincipalName }) -join '; '
                            } else { '(no app registration in this tenant)' }
        }
    } | Format-Table -AutoSize

# Legacy connector accounts (Directory Synchronization Accounts role)
$dsaRole = Get-MgDirectoryRole | Where-Object RoleTemplateId -eq 'd29b2b05-8046-44ba-8758-1e26182fcf32'
if ($dsaRole) {
    Get-MgDirectoryRoleMember -DirectoryRoleId $dsaRole.Id |
        Select-Object Id, @{ n = 'UserPrincipalName'; e = { $_.AdditionalProperties.userPrincipalName } }
}
What I look for in the output: more Connect applications than you have servers, client secrets on an application that should only have a certificate, credentials on the service principal object rather than the application, owners at all, and connector accounts for servers that no longer exist.

Monitoring the sync sign-ins

With sign-in logs in a Log Analytics workspace (the service principal sign-ins need their own diagnostic setting category), the application side is one query. The credential thumbprint lets you tie each sign-in to a server's certificate:
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(14d)
| where ResourceIdentity == "6bf85cfa-ac8a-4be5-b5de-425a0d0dc016"
    or ResourceDisplayName == "Microsoft Entra AD Synchronization Service"
| summarize SignIns = count(), LastSeen = max(TimeGenerated), IPs = make_set(IPAddress)
    by ServicePrincipalName, ServicePrincipalId, ServicePrincipalCredentialThumbprint, ResultType, ConditionalAccessStatus
For the connector accounts, take the object IDs from the script above:
let connectorAccounts = dynamic(["<object id 1>", "<object id 2>"]);
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where UserId in (connectorAccounts)
| summarize SignIns = count(), LastSeen = max(TimeGenerated)
    by UserPrincipalName, AppDisplayName, ResourceDisplayName, ResourceIdentity, IPAddress, ResultType, ConditionalAccessStatus
A server that has been onboarded should disappear from the second result and show up in the first. Anything signing in as a Connect application from an IP address that isn't one of your Connect servers should be handled as an incident. A connector account still signing in weeks after its server reports application authentication means something else is using that password. On the server itself, Connect writes event 1011 to the Application log when the certificate is within 150 days of expiry and event 1012 when it has expired, which matters most if you brought your own certificate.

Checking version and identity per server

Run this on every Connect server, staging servers included, because they all have their own identity and their own version:
(Get-Item 'C:\Program Files\Microsoft Azure AD Connect\AzureADConnect.exe').VersionInfo.ProductVersion
Get-ADSyncEntraConnectorCredential
Get-ADSyncScheduler | Select-Object StagingModeEnabled, SyncCycleEnabled
ConnectorIdentityType tells you whether the server still uses the connector account (ServiceAccount) or the application (Application); the wizard shows the same under View or export current configuration, including the application's client ID. Under the version support policy every 2.x release retires 12 months after its successor appears: 2.4.18.0 goes out of support on 9 October 2025 and 2.4.21.0 on 15 November 2025. New builds are only available from the Microsoft Entra admin center, not from the Download Center. And there is now a hard floor. At the end of September Microsoft published that Connect Sync uses Microsoft Entra AD Synchronization Service for synchronization and that every server must run 2.5.79.0 or later by 30 September 2026. After that date all synchronization services on older versions fail until the server is upgraded, so a server that doesn't get the auto-upgrade, for example because auto-upgrade is switched off, has a year to get there.

Before the auto-upgrade reaches your remaining servers, run Get-ADSyncEntraConnectorCredential on each of them, note which ones are still below 2.5.79.0, add the egress IP of every server that reports Application to the named location your workload identity policies allow, and check that your All users policies exclude the Directory Synchronization Accounts role rather than named accounts.

Update September 2026: On 29 September 2026 Microsoft moved the deadline to 7 April 2027 and raised the bar: every server needs 2.6.84.0 or later and must be configured for application-based authentication, because legacy authentication with the connector account is being retired. See the version release history. Microsoft also dropped the automatic switch described above: from 2.6.84.0 existing servers are no longer moved to application-based authentication by themselves. Servers that still report ServiceAccount need the wizard or the PowerShell steps before that date, or they stop synchronizing.

Written by an Argus IT expert

Want an expert like this in your team, or work like this yourself in security, IAM or cloud?

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens has worked in security and identity for more than ten years, eight of them at Microsoft in the Identity and Network Access product group. She founded Argus IT in 2023 and has a soft spot for the hidden gems in Entra ID. CISSP, CCSP, CISM, CCSK and Microsoft Certified Trainer.

Stay in the Loop

Subscribe to our newsletter for a friendly nudge whenever we publish a new article or have news to share.