De first-party app van Entra Connect Sync in Conditional Access en sign-in logs
01-10-2025 · Samantha Kloos-KilkensVanaf Entra Connect Sync 2.5.76.0 stapt een server die nog met het oude connector-gebruikersaccount inlogt zelf over op een applicatie met een certificaat, en de resource waarvoor die applicatie tokens aanvraagt is een first-party service principal van Microsoft: Microsoft Entra AD Synchronization Service (app ID 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016). Daarmee verandert welke Conditional Access-policies op je sync van toepassing zijn, wie zich als je sync kan voordoen en waar de sign-ins terechtkomen. Eind september heeft Microsoft er ook een deadline aan gekoppeld: elke Connect-server moet uiterlijk 30 september 2026 op 2.5.79.0 of hoger draaien. In deze blog: wat de app is, hoe beide sync-identiteiten zich tot Conditional Access verhouden, hoe je ze monitort en hoe je per server controleert welke versie en welke identiteit hij gebruikt.
Foto: Getty Images via Unsplash
Wat Microsoft Entra AD Synchronization Service is
Application-based authentication werd generally available, en de standaard, in versie 2.5.76.0, uitgebracht op 31 juli met auto-upgrade vanaf 14 augustus. Vanaf die versie wordt een server die met gebruikersnaam en wachtwoord authenticeert binnen zes uur automatisch omgezet naar applicatie-authenticatie; handmatig onboarden kan vanaf 2.5.3.0. In de standaardmodus maakt Connect een single-tenant applicatie in je tenant aan, bewaart het certificaat in de TPM als die er is (anders in de software key storage provider, gemarkeerd als niet-exporteerbaar) en roteert het zelf. Versie 2.5.79.0 volgde op 1 september, met gefaseerde auto-upgrade vanaf 4 september, en de release notes gaan bijna volledig over applicatie-authenticatie: een fallback als ondertekenen met de TPM mislukt, servers met FIPS-modus en het opruimen van certificaten die na een mislukte setup achterblijven.
In veel tenants is de sync-identiteit deze zomer dus geruisloos veranderd, van een gebruiker met een wachtwoord naar een service principal met een certificaat. Over die identiteitswissel gaat het grootste deel van deze blog, omdat die bepaalt welke van je policies op de sync van toepassing zijn.
Twee sync-identiteiten en hoe Conditional Access ze ziet
Na het omzetten logt de server in als zijn single-tenant service principal, met de client credentials-flow. Policies voor gebruikers gelden niet voor die sign-in. Conditional Access for workload identities wel: dat geldt voor single-tenant service principals die in je eigen tenant geregistreerd zijn, en dat is precies wat Connect aanmaakt. Je hebt er Workload Identities Premium-licenties voor nodig, de enige grant is Block en de condities zijn locatie en service principal risk. Heb je een locatiepolicy voor workload identities waar de Connect-applicatie onder valt, direct of omdat alle service principals in de tenant zijn opgenomen (ServicePrincipalsInMyTenant in Graph), dan moeten de uitgaande IP-adressen van elke Connect-server in de toegestane named location staan. Anders wordt de tokenaanvraag geblokkeerd en mislukt de sync-cyclus. Omdat het omzetten na een upgrade automatisch gebeurt, ook na een auto-upgrade, kan dat buiten elk change window vallen. De What If-tool accepteert single-tenant service principals, dus je kunt elke Connect-applicatie testen voordat hij gaat inloggen.
Wie zich als je sync kan voordoen
De gebruikelijke hardeningmaatregelen voor applicaties passen niet goed op dit tweetal. App instance property lock is, zoals Microsoft het beschrijft, iets wat de owner van een multitenant applicatie instelt om credentials op zijn service principals in andere tenants te vergrendelen. Jij bent geen owner van de Microsoft-resource, en de applicatie van Connect is single-tenant. "Assignment required" en scripts die Microsoft service principals uitschakelen die niemand herkent, zijn juist een risico in de andere richting: Microsoft beschrijft deze app als wat synchronisatie mogelijk maakt, ik heb geen documentatie gevonden over hoe de sync zich gedraagt als assignment required erop staat, en dat zou ik niet in productie willen uitzoeken. Ik zou hem expliciet uitsluiten van zulke opschoonacties.
Werkt applicatie-authenticatie eenmaal, dan adviseert Microsoft het oude connector-account te verwijderen met Remove-ADSyncAADServiceAccount, of bij een eigen account dat niet weg kan, de rol Directory Synchronization Accounts eraf te halen. Connector-accounts van uitgefaseerde servers zijn identiteiten met alleen een wachtwoord en sync-rechten, die je Conditional Access-baseline per ontwerp uitsluit.
Het script hieronder toont de Microsoft-resource, elke principal met een app role erop met de credentials en owners van de bijbehorende applicatie, en de connector-accounts die nog bestaan.
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 met een app role op de sync-resource (de Connect-applicaties)
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
# Oude connector-accounts (rol Directory Synchronization Accounts)
$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 } }
}
De sign-ins van de sync monitoren
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
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
Versie en identiteit per server controleren
(Get-Item 'C:\Program Files\Microsoft Azure AD Connect\AzureADConnect.exe').VersionInfo.ProductVersion
Get-ADSyncEntraConnectorCredential
Get-ADSyncScheduler | Select-Object StagingModeEnabled, SyncCycleEnabled
Draai Get-ADSyncEntraConnectorCredential op je resterende servers voordat de auto-upgrade ze bereikt, noteer welke nog onder 2.5.79.0 zitten, zet het uitgaande IP-adres van elke server die Application meldt in de named location die je workload identity-policies toestaan, en controleer of je All users-policies de rol Directory Synchronization Accounts uitsluiten in plaats van accounts op naam.
Update september 2026: Op 29 september 2026 verschoof Microsoft de deadline naar 7 april 2027 en legde de lat hoger: elke server moet op 2.6.84.0 of hoger draaien en ingesteld zijn op application-based authentication, omdat legacy authenticatie met het connector-account wordt uitgefaseerd. Zie de version release history. Microsoft heeft ook de automatische omschakeling van hierboven geschrapt: vanaf 2.6.84.0 worden bestaande servers niet meer vanzelf omgezet naar application-based authentication. Servers die nog ServiceAccount melden, moeten vóór die datum via de wizard of PowerShell worden omgezet, anders stoppen ze met synchroniseren.
Bronnen
- What's new-archief voor Microsoft Entra (december 2024: eigen first-party resource-applicatie voor sync)
- Authenticate to Microsoft Entra ID by using application identity
- Microsoft Entra Connect: Version release history
- Microsoft Entra Connect: Accounts and permissions (Microsoft Entra Connector-account)
- Conditional Access-policy: Require MFA for all users (uitsluiting Directory Synchronization Accounts)
- Conditional Access for workload identities
- Conditional Access What If-tool
- Conditional Access filters for applications
- App instance property lock configureren
- Tabelreferentie AADServicePrincipalSignInLogs
- Versie van de provisioning agent of Connect Sync controleren
- Hardening update to Microsoft Entra Connect Sync