Wat de sourceAnchor is en waarom die onveranderlijk moet zijn
Elke gebruiker die vanuit on-premises Active Directory naar Entra ID wordt gesynchroniseerd, heeft een sourceAnchor: een waarde die het AD-object permanent koppelt aan het Entra ID-object. In Entra ID zie je die waarde terug als de ImmutableID op het gebruikersobject. De naam zegt het al — deze waarde hoort nooit te veranderen gedurende de levensduur van een identiteit.
Verandert de sourceAnchor toch, dan ziet de synchronisatie het AD-object en het cloudobject niet langer als hetzelfde object. Het gevolg: dubbele gebruikers, gebroken mailboxkoppelingen, gebruikers die niet meer kunnen inloggen, of synchronisatiefouten die de hele omgeving raken. In omgevingen die wij overnemen van andere beheerders is een verkeerd gekozen sourceAnchor een van de meest voorkomende tijdbommen.
Het probleem met objectGUID
Oudere installaties van Azure AD Connect (nu Entra Connect) gebruiken standaard het attribuut objectGUID als sourceAnchor. Dat leek destijds logisch: elke objectGUID is gegarandeerd uniek en verandert niet — zolang het object binnen hetzelfde forest blijft.
En daar zit precies het probleem. De objectGUID wordt door Active Directory zelf uitgegeven en is niet overdraagbaar:
- Cross-forest migratie: verplaats je een gebruiker naar een ander forest (bijvoorbeeld bij een fusie, overname of domeinconsolidatie), dan krijgt het object in het nieuwe forest een nieuwe objectGUID. De koppeling met het bestaande Entra ID-object breekt.
- AD-herbouw of restore: moet een domein opnieuw worden opgebouwd, dan krijgen alle objecten nieuwe GUID's.
- Migratie naar een nieuwe AD-omgeving: hetzelfde verhaal — nieuwe objecten, nieuwe GUID's, gebroken matches.
Het attribuut mS-DS-ConsistencyGuid lost dit op. Het is een schrijfbaar attribuut dat je kunt meenemen bij een migratie: je kopieert de waarde simpelweg naar het object in het nieuwe forest, en de koppeling met Entra ID blijft intact. Microsoft raadt mS-DS-ConsistencyGuid al jaren aan als standaard; nieuwe installaties van Entra Connect gebruiken het automatisch. Maar omgevingen die ooit met een oude versie zijn ingericht, draaien vaak nog steeds op objectGUID — tot het misgaat.
Hoe de migratie werkt
Het goede nieuws: Entra Connect ondersteunt de overstap van objectGUID naar mS-DS-ConsistencyGuid als ingebouwd scenario, zonder dat bestaande objecten opnieuw gematcht hoeven te worden.
Het principe is eenvoudig. Bij de omschakeling schrijft Entra Connect voor elk gesynchroniseerd object de huidige objectGUID-waarde naar het (lege) mS-DS-ConsistencyGuid-attribuut in AD. De waarde van de sourceAnchor verandert dus niet — alleen het attribuut waar die waarde vandaan komt. Daarom blijven alle bestaande koppelingen intact. Vanaf dat moment is de waarde verplaatsbaar: bij een toekomstige forest-migratie neem je het attribuut mee en blijft de identiteit gekoppeld.
De omschakeling zelf doe je via de Entra Connect-wizard: Configure → Configure Source Anchor. De wizard detecteert dat objectGUID in gebruik is en biedt de migratie naar mS-DS-ConsistencyGuid aan.
Valkuil 1: schrijfrechten van het connector-account
Entra Connect moet het mS-DS-ConsistencyGuid-attribuut kunnen beschrijven op alle gesynchroniseerde objecten. Het AD-connector-account (het serviceaccount waarmee Connect in AD leest en schrijft) heeft die schrijfrechten niet altijd — zeker niet als het account ooit handmatig met minimale rechten is ingericht.
Controleer vóór de migratie of het connector-account schrijfrechten heeft op mS-DS-ConsistencyGuid voor alle relevante OU's. Ontbreken die rechten, dan schrijft de wizard het attribuut bij een deel van de objecten niet weg en eindig je met een halfslachtige migratie: sommige objecten met gevulde mS-DS-ConsistencyGuid, andere zonder. Dat is lastig te troubleshooten, omdat de synchronisatie op het oog gewoon blijft draaien.
Valkuil 2: mS-DS-ConsistencyGuid is al in gebruik
Het attribuut kan al gevuld zijn. Dat zie je bij omgevingen waar ooit een eerdere migratie is gedaan, waar een andere identity-oplossing (zoals Okta of een eerdere sync-tool) het attribuut heeft geclaimd, of waar beheerders het handmatig hebben gevuld voor een hard match.
Inventariseer dit vooraf. Objecten waarvan de bestaande waarde afwijkt van de objectGUID verdienen aparte aandacht: is de afwijkende waarde correct (bijvoorbeeld na een eerdere cross-forest verhuizing), dan moet die juist behouden blijven. Is de waarde een overblijfsel van iets ouds, ruim die dan gecontroleerd op voordat je de wizard draait. Een simpele PowerShell-inventarisatie zet je in vijf minuten op en voorkomt uren zoekwerk achteraf.
Valkuil 3: AD FS en de ImmutableID-claim
Federeert de omgeving nog via AD FS, dan wordt de ImmutableID als claim uitgegeven bij het inloggen. De claim rules verwijzen dan naar het attribuut dat als sourceAnchor dient. Beheert Entra Connect de AD FS-farm, dan werkt de wizard de claim rules automatisch bij. Is AD FS handmatig ingericht — wat in de praktijk vaak zo is — dan moet je de issuance rule voor de ImmutableID zelf aanpassen naar mS-DS-ConsistencyGuid.
Vergeet je dit, dan geeft AD FS na de migratie nog de oude claim af en kunnen federatieve logins stukgaan. Plan dit als expliciete stap, inclusief test met een pilotgebruiker.
Valkuil 4: meerdere Connect-servers en staging mode
Draait er naast de actieve Entra Connect-server een staging-server (aanrader voor elke serieuze omgeving), dan moeten beide servers dezelfde sourceAnchor-configuratie hebben. Werk je alleen de actieve server bij en faalt die ooit, dan neemt de staging-server het over met de oude configuratie — met alle gevolgen van dien.
Zelfde aandachtspunt bij multi-forest omgevingen: de sourceAnchor-keuze geldt voor de hele installatie, dus controleer of het attribuut in álle forests beschikbaar en beschrijfbaar is.
Valkuil 5: de migratie is pas af als het attribuut mee verhuist
De overstap naar mS-DS-ConsistencyGuid is geen doel op zich — het is de voorbereiding op verplaatsbaarheid. Bij een daadwerkelijke cross-forest migratie moet het attribuut ook echt worden meegenomen naar het nieuwe object. Migratietools zoals ADMT kopiëren mS-DS-ConsistencyGuid niet standaard mee; je moet het attribuut expliciet opnemen in de attributenlijst of achteraf via PowerShell overzetten.
Wordt dat vergeten, dan probeert Entra Connect het nieuwe object als nieuw aan te maken en zit je alsnog met een hard match-actie: handmatig de ImmutableID op het cloudobject zetten op basis van de nieuwe waarde. Dat kan, maar het is precies het handwerk dat je met deze migratie wilde voorkomen.
Stappenplan in het kort
- Inventariseer: welke sourceAnchor is nu in gebruik (zie de Entra Connect-configuratie of
Get-ADSyncGlobalSettings), en is mS-DS-ConsistencyGuid ergens al gevuld? - Controleer rechten: schrijfrechten voor het connector-account op mS-DS-ConsistencyGuid, op alle gesynchroniseerde OU's, in alle forests.
- Backup en export: exporteer de huidige Connect-configuratie en documenteer de bestaande ImmutableID's van een steekproef aan gebruikers.
- Draai de wizard op de actieve server: Configure → Configure Source Anchor.
- Werk AD FS bij (indien van toepassing): claim rules voor ImmutableID.
- Werk de staging-server bij met dezelfde configuratie.
- Verifieer: steekproef van objecten — is mS-DS-ConsistencyGuid gevuld met de objectGUID-waarde, en is de ImmutableID in Entra ID ongewijzigd? Test een federatieve login als AD FS in gebruik is.
Uit de praktijk
Wij hebben deze migratie recent uitgevoerd in productieomgevingen, als voorbereiding op domeinconsolidaties. De technische omschakeling zelf duurt minuten; het echte werk zit in de inventarisatie vooraf en het controleren van de randgevallen hierboven. Doe je dat huiswerk, dan merken gebruikers er niets van — en dat is precies de bedoeling.
Staat jouw omgeving (of die van je klant) nog op objectGUID? Wacht dan niet tot een migratie of fusie het probleem acuut maakt. Deze omschakeling is een van de weinige stukken technisch onderhoud die je vrijwel risicoloos vooraf kunt doen, en die je bij de eerstvolgende AD-wijziging dagen werk bespaart.
