Wie bereite ich Azure AD Connect vor, damit UPNs, Attribute und ImmutableID ohne Konflikte synchronisieren?

Architekturgrundlagen: Source of Authority, Objektabgleich und Bedeutung von ImmutableID/SourceAnchor

Azure AD Connect bildet die Brücke zwischen lokalem Active Directory (AD DS) und Entra ID. Technisch entsteht dabei kein „Spiegel“, sondern ein geregelter Objektabgleich: Identitäten werden im Metaverse von Azure AD Connect zusammengeführt, mit Attributen angereichert und anschließend in die Cloud exportiert. Stabil bleibt diese Architektur nur, wenn eindeutig geklärt ist, wo ein Objekt „führend“ verwaltet wird (Source of Authority) und über welchen konstanten Schlüssel ein lokales Objekt in Entra ID wiedererkannt wird (SourceAnchor; in Entra ID als onPremisesImmutableId gespeichert).

In Hybrid-Szenarien liegen die meisten Identitätsdaten initial im lokalen AD DS. Sobald ein Objekt aber einmal in Entra ID als synchronisiert gekennzeichnet ist, gelten wesentliche Identitätsattribute als aus dem lokalen Verzeichnis stammend. Änderungen an diesen Attributen in der Cloud werden dann entweder blockiert oder bei der nächsten Synchronisation wieder überschrieben. Genau an dieser Stelle entscheidet eine saubere Festlegung des Source-of-Authority-Prinzips darüber, ob Betrieb, Troubleshooting und spätere Migrationen kontrolliert möglich sind.

Source of Authority: Wer darf was ändern?

„Source of Authority“ bezeichnet die Instanz, die für ein Attribut oder eine Objektklasse als maßgeblich gilt. Praktisch bedeutet das: Ein synchronisiertes Benutzerkonto wird in Entra ID zwar für Cloud-Dienste genutzt, aber Identitätsstammdaten (z. B. Name, UPN, ProxyAddresses) kommen aus dem lokalen AD DS, sofern die Synchronisationsregeln dies so definieren. Sobald mehrere Systeme als „führend“ agieren, entstehen Drift und Konflikte: Cloud-seitige Korrekturen verschwinden, lokale Änderungen wirken unerwartet, und Supportfälle enden in manuellen Hotfixes statt reproduzierbarer Prozesse.

Die Regel ist daher streng zu interpretieren: Entweder ist ein Objekt cloud-only (Cloud führt), oder es ist synchronisiert (on-prem führt). Mischformen sind nur dann tragfähig, wenn sie explizit über Attribut-Flows, Writeback-Funktionen und klare Zuständigkeiten modelliert werden. Andernfalls wird der Objektabgleich zu einem permanenten „Tauziehen“ zwischen Verzeichnissen.

Objektabgleich in Azure AD Connect: Join, Provisioning und Export

Der Abgleich folgt einem deterministischen Muster: Zunächst importiert Azure AD Connect Objekte aus den Connectoren (AD DS und Entra ID). Anschließend werden sie im Metaverse korreliert (Join) oder neu angelegt (Provisioning). Danach fließen Attribute gemäß Synchronisationsregeln in Richtung Entra ID, bis schließlich der Export die Änderungen in der Cloud schreibt. Kritisch ist, dass der Join-Schritt ein eindeutiges Matching benötigt. Ohne einen stabilen Schlüssel kann ein lokales Objekt nicht verlässlich einem bestehenden Cloud-Objekt zugeordnet werden.

Das Matching erfolgt je nach Zustand und Historie über mehrere Mechanismen. In etablierten Hybrid-Umgebungen dominiert dabei der SourceAnchor (in Entra ID als onPremisesImmutableId gespeichert) als primärer Join-Schlüssel. Daneben existieren „Soft Match“-Verfahren, typischerweise über UPN oder primäre SMTP-Adresse, die aber nur als Übergangsmechanismus taugen und bei Kollisionen riskant werden. Architekturentscheidend ist, dass ein einmal gesetzter, stabiler Anker eine dauerhafte Identität bildet, selbst wenn sichtbare Anmeldenamen (UPN) oder E-Mail-Adressen später geändert werden.

• Metaverse als Schaltstelle: Zusammenführung der Connector-Spaces, Anwendung von Join- und Provisioning-Regeln, danach Attributfluss in Richtung Export.
• Join vor Provisioning: Wenn ein Cloud-Objekt bereits existiert, muss ein lokales Objekt über einen eindeutigen Schlüssel zugeordnet werden; andernfalls entsteht ein zweites Objekt oder ein dauerhafter Synchronisationsfehler.
• Soft Match als Sonderfall: Zuordnung über identische Werte wie userPrincipalName oder proxyAddresses ist fehleranfällig, wenn Dubletten, Namenswechsel oder historisch gewachsene Aliase existieren.
• Hard Match über onPremisesImmutableId: Der in Entra ID gespeicherte Wert onPremisesImmutableId muss zum on-prem SourceAnchor passen; nur dann bleibt die Zuordnung auch bei UPN-/SMTP-Änderungen stabil.

ImmutableID/SourceAnchor: Der unveränderliche Identitätsanker

Der SourceAnchor ist das on-prem Attribut, das Azure AD Connect als dauerhaft eindeutige Identifikation eines AD-Objekts verwendet. In Entra ID wird dieser Wert als onPremisesImmutableId gespeichert (historisch oft „ImmutableID“ genannt). Wichtig ist die funktionale Bedeutung: Nicht der UPN, nicht die E-Mail-Adresse und nicht der Anzeigename definieren die Identität eines synchronisierten Kontos, sondern dieser Anker. Damit wird nachvollziehbar, warum vermeintlich harmlose Änderungen wie das Neu-Erstellen eines Benutzerkontos mit gleichem Namen oder das Zurückspielen eines alten AD-Backups zu massiven Zuordnungsproblemen führen können.

In vielen Standardinstallationen nutzt Azure AD Connect mS-DS-ConsistencyGuid als SourceAnchor und befüllt dieses Attribut beim erstmaligen Synchronisieren aus der objectGUID. Die objectGUID selbst kann sich in bestimmten Migrations- oder Wiederherstellungsszenarien ändern (z. B. Objekt-Neuanlage), während die ConsistencyGuid als explizites, kontrollierbares Ankerattribut gedacht ist. Entscheidend ist nicht der konkrete Attributname, sondern die Garantie: Der SourceAnchor muss pro Objekt eindeutig sein, darf sich nicht ändern und muss über den gesamten Lebenszyklus konsistent bleiben.

Der in Entra ID gespeicherte onPremisesImmutableId-Wert ist typischerweise die Base64-Repräsentation des binären Ankers. Daraus ergeben sich typische Fehlerbilder: Ein Cloud-Objekt existiert bereits ohne passenden onPremisesImmutableId (cloud-only), oder es existiert mit einer onPremisesImmutableId, die zu einem anderen lokalen Objekt gehört. In beiden Fällen scheitert der Join. Die korrekte Behebung hängt nicht von „Retry“-Mechanismen ab, sondern von sauberer Identitätsführung: Entweder wird das Cloud-Objekt gezielt mit dem richtigen lokalen Objekt „hard gematcht“ (onPremisesImmutableId korrekt setzen) oder es wird bereinigt, damit Azure AD Connect eindeutig provisionieren kann.

• SourceAnchor prüfen (on-prem): Get-ADUser -Identity <SamAccountName> -Properties mS-DS-ConsistencyGuid,objectGUID | Select SamAccountName,mS-DS-ConsistencyGuid,objectGUID
• ImmutableID prüfen (Cloud): Get-MgUser -UserId <UPN> -Property Id,UserPrincipalName,OnPremisesSyncEnabled,OnPremisesImmutableId | Select UserPrincipalName,OnPremisesSyncEnabled,OnPremisesImmutableId
• Konsequenz bei Objekt-Neuanlage: Wird ein Benutzer in AD gelöscht und neu erstellt, entsteht ein neuer Anker; ohne kontrolliertes Matching führt das häufig zu Dubletten oder zu exportseitigen Fehlern durch bereits belegte Werte wie proxyAddresses.
• Schutz vor Restore-Effekten: Nach AD-Restore oder autoritativer Wiederherstellung muss geprüft werden, ob der SourceAnchor pro Objekt weiterhin stabil ist; ein inkonsistenter Anker erzeugt „verwaiste“ Cloud-Objekte oder onPremisesImmutableId-Kollisionen.

Identitätsgrenzen: Was ImmutableID nicht löst

ImmutableID/SourceAnchor verhindert keine inhaltlichen Attributkonflikte. Der Anker stellt nur sicher, dass ein Objekt wiedererkannt wird. Kollisionen bei userPrincipalName oder proxyAddresses bleiben davon unberührt und blockieren den Export weiterhin. Ebenso erzwingt der Anker keine fachliche Eindeutigkeit, wenn mehrere lokale Objekte in den Synchronisationsbereich fallen, die identische Anmelde- oder Mailattribute tragen. Deshalb gehört zur Architekturentscheidung für den SourceAnchor immer auch eine strikte Hygiene bei eindeutigen Attributen, sowie ein klarer Scope (OU-/Attributfilter), der festlegt, welche Objekte überhaupt als Kandidaten für den Abgleich gelten.

Eine robuste Hybrid-Identität entsteht aus dem Zusammenspiel: eindeutig definierte Source of Authority, ein stabiler SourceAnchor, und konsistente, konfliktfreie Attribute, die in Entra ID global eindeutig sein müssen. Ohne diese Grundlagen wird Azure AD Connect zwar synchronisieren, aber nicht zuverlässig korrelieren — mit allen bekannten Folgen von Dubletten, Exportfehlern und schwer nachvollziehbaren Drift-Effekten.

Vorbereitung im lokalen AD: UPN-Suffixe, Attributqualität, Duplikate, OU-Scopes und Authentifizierungsentscheidung

Die technische Stabilität von Azure AD Connect hängt stärker von der Qualität und Eindeutigkeit der lokalen Active-Directory-Daten ab als von der eigentlichen Synchronisationsengine. Probleme entstehen typischerweise dort, wo Identitäten historisch gewachsen sind: mehrere Namensschemata, inkonsistente Attribute, nicht mehr benötigte Objekte oder unklare Zuständigkeiten zwischen on-premises und Cloud. Vor der Installation sollten deshalb Identitätsmerkmale, Filterumfang und Authentifizierungsmodell festgelegt und im Verzeichnis „durchdekliniert“ werden.

UPN-Suffixe vereinheitlichen und routbare Domänen sicherstellen

Für die Benutzeranmeldung in Entra ID gilt der UPN als primärer Anmeldebezeichner. Zwar kann Azure AD Connect auch mit abweichenden lokalen UPNs betrieben werden, in der Praxis führen nicht-routbare Suffixe (zum Beispiel .local) jedoch zu Medienbrüchen bei Anmeldung, Zertifikatsnamen, E-Mail-Adresslogik und Benutzerkommunikation. Sauber ist ein UPN, dessen Suffix einer im Tenant verifizierten, öffentlich routbaren Domäne entspricht und dessen Präfix den unternehmensweit definierten Regeln folgt.

Vor der Umstellung sollte geprüft werden, ob alle benötigten UPN-Suffixe im Forest verfügbar sind und ob einzelne Konten Sonderformen tragen (mehrere Suffixe, temporäre Namensräume, nicht erlaubte Zeichen). Entscheidend ist außerdem die Eindeutigkeit: Jeder UPN muss forestweit eindeutig sein, sonst entstehen harte Synchronisationskonflikte. Die Korrektur sollte vor dem ersten Sync erfolgen, damit keine Cloud-Identitäten mit später zu ändernden Logins entstehen.

• UPN-Suffixe im Forest inventarisieren: Get-ADForest | Select-Object -ExpandProperty UPNSuffixes
• Nicht-routbare oder unerwünschte Suffixe finden (Beispiel .local): Get-ADUser -LDAPFilter "(userPrincipalName=*.local)" -Properties userPrincipalName | Select-Object Name,userPrincipalName
• UPN-Eindeutigkeit prüfen (Duplikate): Get-ADUser -Filter * -Properties userPrincipalName | Group-Object userPrincipalName | Where-Object {$_.Count -gt 1} | Select-Object Name,Count

Attributqualität: Eindeutigkeit, Format, Altlasten und Sync-relevante Felder

Azure AD Connect exportiert nicht „den Benutzer“, sondern ein Set aus Attributen, die im Zielsystem zusammengeführt, validiert und teils als Schlüssel interpretiert werden. Konflikte treten auf, wenn Attribute im lokalen AD nicht normiert sind oder wenn Altsysteme Felder zweckentfremdet haben. Typische Beispiele sind fehlerhafte Zeichensätze in mail, veraltete Proxy-Adressen in proxyAddresses, widersprüchliche Namensbestandteile oder nicht eindeutige Werte in Attributen, die in der Organisation als Identitätsanker gedacht sind.

Für hybride Szenarien mit Exchange oder Exchange Online ist die Konsistenz von mail, proxyAddresses und mailNickname zentral, weil sich daraus Adressrichtlinien, Reply-Adressen und Objektzusammenführung ergeben. Separat zu bewerten sind Exchange-spezifische Altattribute wie legacyExchangeDN oder msExchRecipientTypeDetails, die bei fehlerhaften Migrationen zu „zombie“-ähnlichen Objekten führen können. Unabhängig davon sollte die Organisation festlegen, welche Felder als authoritative Quelle gelten und welche Felder in der Cloud bewusst nicht überschrieben werden sollen.

• ProxyAddresses-Duplikate prüfen: Get-ADObject -LDAPFilter "(proxyAddresses=*)" -Properties proxyAddresses | ForEach-Object {$dn=$_.DistinguishedName; $_.proxyAddresses | ForEach-Object {[pscustomobject]@{DN=$dn;Proxy=$_}}} | Group-Object Proxy | Where-Object {$_.Count -gt 1} | Select-Object Name,Count
• Leere oder fehlende Mailattribute finden: Get-ADUser -Filter * -Properties mail | Where-Object { [string]::IsNullOrWhiteSpace($_.mail) } | Select-Object Name,UserPrincipalName
• Verdächtige Zeichen im UPN (Beispiel Leerzeichen) identifizieren: Get-ADUser -Filter * -Properties userPrincipalName | Where-Object {$_.userPrincipalName -match "\s"} | Select-Object Name,userPrincipalName

Duplikate, Mehrfachobjekte und harte Konflikte vor dem ersten Export eliminieren

Duplikate sind in hybriden Umgebungen selten „zufällig“. Häufig existieren parallele Konten für Administratoren, für Dienstzwecke, aus Mandantenwechseln oder aus früheren Migrationstests. Azure AD Connect kann solche Situationen nicht „erraten“: Treffen zwei lokale Objekte auf dieselbe Cloud-Identität oder kollidieren cloudseitige Unique-Constraints (UPN, primäre SMTP, ProxyAddress), stoppt der Export mit Fehlern oder erzeugt unerwünschte neue Cloud-Objekte.

Besonders kritisch sind Fälle, in denen bereits Cloud-Konten existieren (z. B. durch frühere Cloud-only-Anlage) und später ein lokales Konto denselben UPN oder dieselbe Mailadresse erhält. Dann entscheidet die Matching-Logik zwischen Soft Match (über UPN/SMTP) und Hard Match (über den SourceAnchor, der in Entra ID als onPremisesImmutableId gespeichert ist). Ohne vorherige Bereinigung entstehen verwaiste Cloud-Objekte, doppelte Einträge in der globalen Adressliste oder eine falsch gekoppelte Identität.

• Doppelte sAMAccountName-Werte im Scope finden (Indikator für Altlasten bei mehreren Domänen): Get-ADUser -Filter * -Properties sAMAccountName | Group-Object sAMAccountName | Where-Object {$_.Count -gt 1} | Select-Object Name,Count
• Verdächtige „kopierte“ Benutzerobjekte erkennen (Beispiel identische Mailadresse): Get-ADUser -Filter * -Properties mail | Where-Object {$_.mail} | Group-Object mail | Where-Object {$_.Count -gt 1} | Select-Object Name,Count
• Cloud-Objekte für spätere Korrelation vorbereiten (Grundlage für Abgleichlisten): Get-MgUser -All -Property Id,UserPrincipalName,Mail,OnPremisesImmutableId | Select-Object Id,UserPrincipalName,Mail,OnPremisesImmutableId

OU-Scopes und Filterlogik: nur synchronisieren, was betrieben werden soll

OU-Filter sind kein kosmetischer Schalter, sondern Governance: Sie definieren, welche Objekte überhaupt in die Identitätskette aufgenommen werden. Ein zu großer Scope zieht Altobjekte, Testkonten, Schulungs- oder Laborstrukturen sowie historische Gruppen nach Entra ID und erschwert späteres Aufräumen, weil gelöschte Cloud-Objekte Wiederherstellungsfristen und Abhängigkeiten (z. B. Lizenzen, Teams, Besitzerrollen) auslösen können. Ein zu kleiner Scope wiederum führt zu unvollständiger Adressierung und unklaren Verantwortlichkeiten.

Bewährt ist ein expliziter, dokumentierter Synchronisationsbereich: produktive Benutzer, benötigte Gruppen, technische Konten nur bei begründetem Bedarf. Dienstkonten ohne Cloud-Nutzung, Built-in-Administratoren, Break-Glass-Accounts und reine Server- oder Applikations-Identitäten verbleiben typischerweise außerhalb des Scopes. Zusätzlich sollten Ausschlussregeln für deaktivierte Konten und Quarantäne-OUs organisatorisch verankert werden, auch wenn die eigentliche Filterung in Azure AD Connect über OU-Scopes oder Synchronisationsregeln erfolgt.

• Synchronisations-OU als Vertrag definieren: OU=Identities,OU=Prod,DC=contoso,DC=com
• Quarantäne für ungeklärte Objekte vorsehen: OU=Quarantine,OU=IAM,DC=contoso,DC=com
• Objekte im geplanten Scope zählen (Planungskennzahl): Get-ADUser -SearchBase "OU=Identities,OU=Prod,DC=contoso,DC=com" -Filter * | Measure-Object
Get-ADGroup -SearchBase "OU=Identities,OU=Prod,DC=contoso,DC=com" -Filter * | Measure-Object

Authentifizierungsentscheidung: PHS, PTA oder Föderation als Architekturvorgabe

Die Wahl zwischen Password Hash Sync (PHS), Pass-Through Authentication (PTA) und Föderation wirkt direkt auf Verfügbarkeit, Incident-Handling und das Identity-Operating-Model. Die Entscheidung sollte vor der Installation fallen, weil sie Abhängigkeiten (Agenten, Zertifikate, Netzwerkpfade), Rollout-Reihenfolgen und Betriebskonzepte prägt. In vielen Umgebungen gilt PHS als robustes Basismodell, während PTA zusätzliche on-premises-Abhängigkeiten einführt. Föderation bleibt in Spezialfällen relevant, etwa bei bestehenden SSO-Ökosystemen oder spezifischen Anforderungen, erhöht aber Komplexität und Betriebsaufwand.

Unabhängig vom Modell müssen Anmeldepfade, Notfallverfahren und Monitoring definiert werden: Was passiert bei WAN-Ausfall, bei Agent-Störungen oder bei Störungen der Federation-Infrastruktur? Welche Konten bleiben cloud-only als Break-Glass? Welche Conditional-Access-Policies sind von der Hybrid-Anmeldung abhängig? Diese Fragen sind Teil der Vorbereitung im lokalen AD, weil sie häufig Anpassungen an Kontentypen, OU-Zuordnung und Attributpflege nach sich ziehen.

Fehlerbilder und Betrieb: UPN-Konflikte, doppelte Benutzer, verwaiste Cloud-Objekte, ImmutableID-Kollisionen sowie Test, Monitoring und Dokumentation

Im laufenden Hybridbetrieb treten Störungen selten „im Sync-Tool“ auf, sondern an Kanten zwischen lokalen Identitäten und Cloud-Identitäten: uneindeutige Anmeldekennungen, inkonsistente Attribute, falsche Join-Entscheidungen oder Objekte, die ihre Zuordnung verloren haben. Azure AD Connect (Entra Connect Sync) arbeitet deterministisch: Er erstellt oder verknüpft Cloud-Objekte auf Basis der konfigurierten Join-Regeln und des resultierenden sourceAnchor (typischerweise mS-DS-ConsistencyGuid) und schreibt den daraus abgeleiteten Wert als onPremisesImmutableId in Entra ID. Fehlerbilder lassen sich deshalb zuverlässig über Metadaten, Sync-Regeln und eindeutige Identifier erklären – und ebenso sauber beheben.

UPN-Konflikte und Anmeldeidentität: Ursachen und Korrekturpfade

UPN-Konflikte zeigen sich meist als Anmeldeprobleme oder als Synchronisationsfehler beim Versuch, einen Wert in Entra ID zu setzen, der dort bereits vergeben ist. Der UPN (userPrincipalName) muss tenantweit eindeutig sein. Konflikte entstehen durch parallel existierende Benutzer (Testkonten, Schattenidentitäten), durch nicht standardisierte UPN-Suffixe oder durch nachträgliche Umbenennungen ohne saubere Korrelation zu bereits vorhandenen Cloud-Objekten. Zusätzlich kann die tatsächlich verwendete Anmeldekennung je nach Client/Prompt auch durch „sign-in hints“ (z. B. zuletzt verwendete Identität) beeinflusst werden; das ändert aber nichts daran, dass der UPN in Entra ID eindeutig sein muss.

• UPN-Eindeutigkeit lokal prüfen: Get-ADUser -LDAPFilter "(userPrincipalName=*)" -Properties userPrincipalName | Group-Object userPrincipalName | Where-Object {$_.Count -gt 1} | Select-Object Name,Count
• UPN-Suffix-Verfügbarkeit verifizieren: Entra ID akzeptiert nur verifizierte Domänen; technische Prüfung über Get-MgDomain (Microsoft Graph PowerShell) und Abgleich mit den lokalen UPN-Suffixen.
• Kollisionsauflösung mit geringem Risiko: UPN des nicht-produktiven oder falschen Objekts lokal ändern, danach Delta-Sync auslösen: Start-ADSyncSyncCycle -PolicyType Delta
• Anmeldealias stabil halten: Bei Exchange-Hybrid sicherstellen, dass primäre SMTP und Aliase konsistent bleiben (z. B. proxyAddresses), um unerwartete Effekte bei Autodiscover, Reply-Adressen und Client-Vervollständigung zu vermeiden.

Doppelte Benutzer: Soft Match, Hard Match und sauberes „Join“-Verhalten

Doppelte Benutzer entstehen, wenn Entra Connect ein Objekt nicht mit einem bereits existierenden Cloud-Objekt verknüpft, sondern ein neues anlegt. Auslöser sind häufig: ein bereits vorab angelegter Cloud-Benutzer (z. B. durch Pilot, Self-Service oder Drittprodukt), abweichende primäre SMTP/UPN-Werte, oder ein geänderter sourceAnchor. Der Abgleich erfolgt je nach Konfiguration über Soft Match (z. B. UPN/SMTP) oder Hard Match über onPremisesImmutableId. In modernen Designs gilt: Der sourceAnchor darf nicht „wechseln“, sonst verliert das Cloud-Objekt seine Bindung zur lokalen Identität.

Verwaiste Cloud-Objekte: „In Cloud, aber ohne lokalen Ursprung“

Verwaiste Objekte sind Cloud-Identitäten ohne gültigen lokalen Gegenpart oder ohne funktionierende Verknüpfung. Häufige Szenarien sind: Objekte wurden lokal gelöscht, während in Entra ID noch Lizenzen, Postfächer, App-Zuordnungen oder Gerätebeziehungen bestehen; OU-Filter wurden geändert und nehmen Benutzer unbeabsichtigt aus dem Scope; oder es kam zu Restore-/Rebuild-Vorgängen, die den sourceAnchor veränderten. Operativ kritisch wird das, wenn Benutzer weiterhin zugreifen können (z. B. weil das Objekt nicht mehr als synchronisiert gilt) oder wenn automatisierte Provisionierung auf „falsche“ Identitäten referenziert.

• Scope-Drift erkennen: Änderungen an OU-/Attributfiltern mit einem Export des Connector Space vergleichen; im Zweifel Delta- und Full-Sync trennen: Start-ADSyncSyncCycle -PolicyType Initial
• Cloud-Objektstatus prüfen: Synchronisierungsmetadaten über Get-MgUser -UserId <UPN> -Property Id,UserPrincipalName,OnPremisesSyncEnabled,OnPremisesImmutableId
• Kontrollierte Bereinigung: Wenn ein Objekt definitiv nicht mehr on-prem verwaltet werden soll, muss der Betriebsprozess die Verantwortlichkeit klären (Source of Authority), bevor Lizenzen entfernt oder Identitäten gelöscht werden; Löschungen bevorzugt über definierte „Deprovisioning“-Schritte statt Ad-hoc.

ImmutableID-Kollisionen und SourceAnchor-Fehler: wenn Identitäten „zusammenfallen“

Eine onPremisesImmutableId-Kollision liegt vor, wenn zwei lokale Objekte (oder ein neu aufgebautes Objekt) denselben sourceAnchor liefern und damit denselben onPremisesImmutableId-Wert in Entra ID beanspruchen. Praktisch passiert das bei unsauberem Klonen von Benutzerobjekten, bei Restore-Szenarien ohne Erhalt der Konsistenz-GUID oder bei manuellen Eingriffen in das mS-DS-ConsistencyGuid-Attribut. Die Korrektur erfordert forensische Genauigkeit: Welches Objekt ist das „Original“, welche Systeme referenzieren es (Mailbox, OneDrive, Apps), und welche Anmeldekennungen müssen erhalten bleiben. Ohne eindeutige Entscheidung drohen Folgefehler wie unerwartete Lizenzzuordnungen oder Zugriff über die falsche Identität.

• SourceAnchor-Wert lokal auslesen: Get-ADUser -Identity <SamAccountName> -Properties mS-DS-ConsistencyGuid | Select-Object SamAccountName,@{n="sourceAnchor";e={$_."mS-DS-ConsistencyGuid"}}
• ImmutableID in Entra ID prüfen: Get-MgUser -UserId <UPN> -Property Id,UserPrincipalName,OnPremisesImmutableId
• Kollision technisch auflösen: Den falschen Duplikat-Anchor lokal entfernen oder korrekt neu setzen (nur mit Change-Freigabe und nachvollziehbarer Zuordnung), anschließend Full Sync: Start-ADSyncSyncCycle -PolicyType Initial

Test, Monitoring und Dokumentation: stabiler Betrieb ohne Blindflug

Synchronisationen müssen als Betriebsprozess verstanden werden: reproduzierbar testbar, kontinuierlich überwacht und revisionsfähig dokumentiert. Tests sollten nicht nur „läuft ein Delta durch“ verifizieren, sondern die kritischen Pfade abdecken: Join-Verhalten bei Neuanlage, Änderungen an UPN/SMTP, OU-Scope-Änderungen, Deprovisioning und Restore-Szenarien. Für den Betrieb zählt zudem die Trennung zwischen Konfigurationsänderung (Sync-Regeln, Filter, Anmeldeverfahren) und regulärem Lauf, weil Konfigurationsänderungen häufig Initial-Synchronisationen auslösen und damit größere Objektmengen bewegen.

• Synchronisationsstatus automatisiert abfragen: Get-ADSyncScheduler
Get-ADSyncRunProfileResult (falls verfügbar) bzw. Auswertung der Run-History im Synchronization Service Manager.
• Ereignisprotokolle gezielt nutzen: Relevante Windows Event Logs auf dem Connect-Server (u. a. Anwendungen/Dienstprotokolle des Synchronisationsdienstes) zentral einsammeln; Alarmierung auf Run-Fehler, Connector-Fehler und Export-Fehlschläge.
• Änderungen nachvollziehbar halten: Versionierte Dokumentation von sourceAnchor-Entscheidung, OU-/Attributfilter, Join-Regeln, Hard-Match-Prozessen, Break-Glass-Konten sowie Wartungsfenstern und Verantwortlichkeiten.
• Testläufe kontrollieren: Für risikoreiche Anpassungen (z. B. Filteränderungen) zuerst Pilot-OU, dann stufenweise Erweiterung; nach jeder Stufe Export-Fehler und Objektanzahl-Deltas bewerten, bevor produktiver Umfang erweitert wird.