De first-party app van Entra Connect Sync in Conditional Access en sign-in logs

01-10-2025 · Samantha Kloos-Kilkens

Vanaf 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.

Hoogspanningsmasten met oplichtende kabels bij zonsondergang Foto: Getty Images via Unsplash

Wat Microsoft Entra AD Synchronization Service is

Microsoft noemde de app voor het eerst in de release notes van december 2024 (inmiddels in het What's new-archief): een eigen first-party applicatie voor de synchronisatie tussen Active Directory en Microsoft Entra ID, uitgerold in tenants die Connect Sync of Cloud Sync gebruiken. Je vindt hem onder Enterprise applications als je op het app ID zoekt met het filter op applicatietype op Microsoft applications. De bruikbaarste beschrijving staat op de Learn-pagina Authenticate to Microsoft Entra ID by using application identity. In de sectie over Bring Your Own Application is de app de resource: de Connect-applicatie heeft de app role ADSynchronization.ReadWrite.All op Microsoft Entra AD Synchronization Service nodig (hetzelfde app ID in elke cloud), en bij password writeback daarnaast drie PasswordWriteback-app roles op de Microsoft password reset service.

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

Zolang een server niet is omgezet, authenticeert hij met het Microsoft Entra Connector-account: een gebruiker met een lang wachtwoord dat niet verloopt en de rol Directory Synchronization Accounts, één per server (stagingservers meegeteld), met een maximum van 20 per tenant. De Conditional Access-templates van Microsoft, zoals Require MFA for all users, sluiten deze accounts uit via de directory role Directory Synchronization Accounts, en precies dat zou ik in elke All users-policy controleren. Een uitsluiting van één account op naam gaat stuk op de dag dat een server opnieuw wordt opgebouwd en de wizard een nieuw account aanmaakt. Dezelfde template adviseert een baseline op All resources zonder app-uitsluitingen, dus de sync-resource uitsluiten in die policy is de verkeerde manier om de sync werkend te houden.

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.
Diagram van de twee manieren waarop een Entra Connect Sync-server bij Microsoft Entra ID inlogt, als connector-gebruikersaccount of als single-tenant applicatie, met de Conditional Access-policies die op elk van toepassing zijn en de resource Microsoft Entra AD Synchronization Service waarmee ze verbinden.
Aan de resourcekant vallen policies op All resources automatisch over de nieuwe service principal. Policies die resources selecteren via filters for applications matchen alleen service principals met het juiste custom security attribute, en een service principal die Microsoft voor je heeft aangemaakt heeft er geen totdat iemand er een toekent. Voor het connector-account zou ik eerst kijken welke resource de sign-ins werkelijk raken voordat je er resourcegerichte targeting of uitsluitingen omheen bouwt; de queries verderop laten dat zien.

Wie zich als je sync kan voordoen

Op de pagina over applicatie-identiteit staat een opmerking die je twee keer moet lezen: de rol Application Administrator kan credentials toevoegen aan een applicatie, "notably the Connect Sync", en zich daarmee als die applicatie voordoen, wat Microsoft een mogelijke elevation of privilege noemt. De Connect-applicatie heeft de permissie waarmee de sync-engine naar Entra ID schrijft, dus iedereen die de credentials ervan kan beheren hoort in dezelfde tier als je Hybrid Identity Administrators. Dat zijn Application Administrators, Cloud Application Administrators en elke owner van de Connect-applicatie.

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 } }
}
Waar ik in de uitvoer op let: meer Connect-applicaties dan je servers hebt, client secrets op een applicatie die alleen een certificaat hoort te hebben, credentials op het service principal-object in plaats van op de applicatie, überhaupt owners, en connector-accounts van servers die niet meer bestaan.

De sign-ins van de sync monitoren

Met sign-in logs in een Log Analytics-workspace (de service principal sign-ins hebben een eigen categorie in de diagnostic settings) is de applicatiekant één query. Via de thumbprint van de credential koppel je elke sign-in aan het certificaat van een server:
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
Voor de connector-accounts neem je de object ID's uit het script hierboven:
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
Een server die is omgezet, hoort uit het tweede resultaat te verdwijnen en in het eerste op te duiken. Alles wat als Connect-applicatie inlogt vanaf een IP-adres dat niet bij je Connect-servers hoort, behandel je als incident. Een connector-account dat weken nadat de server applicatie-authenticatie meldt nog steeds inlogt, betekent dat iets anders dat wachtwoord gebruikt. Op de server zelf schrijft Connect event 1011 naar de Application-log als het certificaat binnen 150 dagen verloopt en event 1012 als het verlopen is, wat vooral telt als je je eigen certificaat hebt meegebracht.

Versie en identiteit per server controleren

Draai dit op elke Connect-server, stagingservers meegeteld, want die hebben allemaal hun eigen identiteit en hun eigen versie:
(Get-Item 'C:\Program Files\Microsoft Azure AD Connect\AzureADConnect.exe').VersionInfo.ProductVersion
Get-ADSyncEntraConnectorCredential
Get-ADSyncScheduler | Select-Object StagingModeEnabled, SyncCycleEnabled
ConnectorIdentityType vertelt je of de server nog het connector-account gebruikt (ServiceAccount) of de applicatie (Application); de wizard toont hetzelfde onder View or export current configuration, inclusief het client ID van de applicatie. Volgens het versiebeleid vervalt elke 2.x-release 12 maanden nadat zijn opvolger verschijnt: 2.4.18.0 valt op 9 oktober 2025 uit support en 2.4.21.0 op 15 november 2025. Nieuwe builds zijn alleen nog via het Microsoft Entra admin center te downloaden, niet via het Download Center. En er is nu een harde ondergrens. Eind september publiceerde Microsoft dat Connect Sync voor synchronisatie Microsoft Entra AD Synchronization Service gebruikt en dat elke server uiterlijk 30 september 2026 op 2.5.79.0 of hoger moet draaien. Daarna mislukken alle synchronisatieservices op oudere versies totdat de server is geüpgraded, dus een server die de auto-upgrade niet krijgt, bijvoorbeeld omdat auto-upgrade uit staat, heeft een jaar om daar te komen.

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.

Geschreven door een expert van Argus IT

Zo’n expert in je team, of zelf zo werken in security, IAM of cloud?

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens werkt al meer dan tien jaar in security en identity, waarvan acht jaar bij Microsoft in de productgroep Identity and Network Access. In 2023 richtte ze Argus IT op en ze heeft een zwak voor de verborgen pareltjes in Entra ID. CISSP, CCSP, CISM, CCSK en Microsoft Certified Trainer.

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.