ADSync Orphaned Objects

Eigentlich dürfte es das gar nicht geben. Objekte in Entra ID haben den "Dirsync"-Status aber im lokalen AD gibt es kein Gegenstück und ADSync kennt das Objekt auch nicht mehr. Aber tatsächlich kann es schon passieren und hier beschreibe ich, wie Sie das Problem lösen.

Zusammenhänge

Auch wenn ich auf anderen Seiten der MSXFAQ schon viel zu ADSync/Entra ID Connect geschrieben habe, möchte ich hier ganz kurz den Vorgang des Löschens und "zurückgelassener" Objekte beschreiben.
Bis auf wenige Sonderfälle ist der Verzeichnisabgleich zwischen dem lokalen AD und dem Tenant eine "One Way Replikation". Die lokalen AD-Verzeichnisse sind immer führend und es werden nur ganz wenig Felder, z.B. msdsConsistencyGUID und manchmal auch Objekte (Groups Writeback) zurückgeschrieben. In der Cloud gibt es daher entweder "CloudOnly"-Konten, die nicht durch den Verzeichnisabgleich verwaltet werden oder die durch ADSync verwalteten Objekte mit dem Flag "DirSync". Damit ADSync die Objekte auch bei Reorganisationen oder Umbenennungen zuverlässig finden kann, versieht er das Cloud-Objekt mit einer "ImmutableID", welche auch im lokalen AD im Feld "msdsConsistencyGUID" gespeichert wird.

Ein Objekt kann aus Sicht von Entra ID Connect auf mehrere Wege als "gelöscht" gelten, z.B.

  • Es wird im AD wirklich gelöscht und landet im AD-Papierkorb und Entra ID-Papierkorb
  •  Es wird in eine OU verschoben, die ADSync nicht repliziert
  • Sie entfernen es aus der Gruppe oder entfernen das Attribute, welches von ADSync als Filter genutzt wird
  • Sie nehmen ADSync die Rechte auf das Objekt.

In allen Fällen sollte ADSync beim nächsten Delta-Import das in der Quelle als "Out of Scope" erkennen und über den Connectorspace der Quelle die Änderung in das Metaverse und dann weiter über den Connectorspace zu Entra ID als Löschung replizieren. Entra ID verschiebt das Objekt dann in den Papierkorb der Cloud, wo es maximal 30 Tage wieder zurückgeholt werden kann. Das macht sogar der DirSync alleine, wenn das lokale Objekt wieder in die Synchronisation aufgenommen wird und der Wert in "msdsConsistencyGUID" erhalten geblieben ist.

Gründe für Orphaned Objekte

Wenn Entra ID Connect so perfekt arbeitet, dann dürfte es eigentlich nie passieren, dass ein lokal "gelöschtes" Objekt dennoch im Entra ID erhalten bleibt. Nun wissen wir aber alle, dass Software nicht immer fehlerfrei ist und es passiert nicht oft aber manchmal schon, das es zu einer Inkonsistenz kommt. Oft ist der Administrator selbst dran schuld. Zwei Szenarien sind einfach zu erklären:

  • Recover aus Entra ID Papierkorb
    Ein Benutzer wurde im lokalen AD gelöscht und Entra ID Connect hat das Objekt auch in Entra ID gelöscht. Ein Administrator hat dann aber das Objekt aus dem Papierkorb in der Cloud zurückgeholt. Damit haben Sie ein "Orphaned Objekt" in Entra ID zu dem es kein lokales Konto gibt.
  • Entra ID-Verlust
    Ihr lokale Entra ID Installation samt Datenbank ist verloren gegangen und wird neu installiert. In der Zwischenzeit haben sie ein lokales Objekte gelöscht oder verändert, so dass es der neu installierte Entra ID Connect nicht mehr importiert und neu matched. Damit bleibt das Objekt in der Cloud als Rest weiter bestehen

Es gibt aber noch weitere Fälle, die nachträglich kaum mehr zu tracken sind, was genau passiert ist, z.B.

  • wenn Administratoren lokal die msdsConsistencyGUID löschen oder verändern
  • Objekte unsauber zwischen Forests verschieben
  • Mehrere Entra ID Connect-Instanzen parallel aktiv laufen lassen
  • Die Synchronisationsregel unpassend verändern
  • Dinge zu schnell ändern ohne ADSync die Zwischenstände erkennen zu lassen

Und das sind mit Sicherheit nicht alle Fälle.

Erkennen

Aber vieleicht ist das der Weg einmal eine Inventur durchzuführen, ob die Objekte in Entra ID und im lokalen AD noch zueinander passen. Zwar ist das lokale AD das eigentlich "führende" Verzeichnis aber in Entra ID könnte es ja unstimmige Objekte geben. Eine Option ist die Suche nach Objekten, die nicht mehr im DirSync sind aber noch OnPremises-Felder haben. Früher habe ich dazu die AzureAD-PowerShell genutzt, aber mittlerweile sollten Sie immer die Graph PowerShell nutzen.

Ein erster Check basiert auf dem Wissen, dass jedes per DirSync in der Cloud verwaltete Objekt auch einen OnPremisesDistinguishedName haben sollte.

Sie können unter https://portal.azure.com die entsprechende Spalte einfach einblenden lassen. Wer mag, kann sogar eine dynamische Verteilergruppe mit dem Kriterium anlegen lassen:

Automatisiert kann das auch per MGGraph PowerShell angefragt werden.

Install-Module Microsoft.Graph -Scope CurrentUser -Repository PSGallery -Force 

Connect-MgGraph `
   -TenantId msxfaqdev.onmicrosoft.com `
   -Scope user.Read.All
# ggfls müssen sie oder ihr Admin eine Zustimmung (Consent) erteilen, damit sie mittels Graph die Daten abrufen dürfen

# Ich lade erst einmal alle User und filtere danach. Bei sehr großen Umgebungen sollten Sie das "-Filter"-Attribut nutzen.
$EntraIDUsers = Get-MgUser -All -Property onPremisesDistinguishedName,OnPremisesSyncEnabled,userprincipalname

# Anzeige der vermutlich disconnectedUser
$EntraIDUsers `
| where { `
        ($_.OnPremisesSyncEnabled -eq $true) `
   -and ($_.onPremisesDistinguishedName -eq $null) `
   }

Es kann durchaus sein, dass einige Objekte hier erscheinen. Bei mir ist es z.B. das DirSync-Konto selbst, welches anscheinend den "Dirsyncstatus" hat aber der OnPremises-DN nicht übertragen wird.

Viel interessanter ist aber ein Abgleich mit dem lokalen AD. Der korrekte Weg zum "Matching" wäre eigentlich die ImmutableID, welche in Entra ID als "OnPremisesImmutableId" gehalten wird. Diese ist aber BASE64-Codiert und passt lokal dann zur msdsConsistencyGUID bzw. ObjectID. Das Feld als also nur für hartgesottene Administratoren gut zu lesen und zu vergleichen. Viel sprechender finde ich hier den Userprincipalname, der bei den meisten, aber nicht allen, Installationen ebenfalls identisch ist.

Das folgende Beispiel funktioniert also nur, wenn der UPN des AD-Kontos und des AzureAD-Kontos identisch ist. Wer mit einer Alternate Login ID arbeitet, muss das Skript dann z.B. auf Mail oder OnPremisesDistinguishedname o.ä. umschreiben.

Wir holen uns daher alle Objekte, die in Entra ID den Status "DirSync" haben in eine Variable und suchen dann anhand des UPN das dazu passende lokale AD-Konto. Auf einen Vergleich der einzelnen Felder verzichte ich hier und auch auf Gruppen, Kontakte und Computerkonten.

Write-Host "Connecting to MGGraph"
Connect-MgGraph `
   -TenantId msxfaqdev.onmicrosoft.com `
   -Scope user.Read.All
# ggfls müssen sie oder ihr Admin eine Zustimmung (Consent) erteilen, damit sie mittels Graph die Daten abrufen dürfen


Write-Host "Loading Entra ID dirsynched Users
$dirsyncusers = Get-Mguser -All -Filter 'onPremisesSyncEnabled eq true' -Properties User

foreach ($dirsyncuser in $dirsyncusers) {
   Write-Host "Processing user $($dirsyncuser.UserPrincipalname)" -nonewline
   if (Get-ADUser -LDAPFilter "(UserPrincipalname=$($dirsyncuser.UserPrincipalname))" {
      Write-Host " - Match" -foregroundcolor green
   }
   else {
      Write-Host " - Missing" -foregroundcolor red
      #send missing user to pipeline
      $dirsyncuser
   }
}

Diese Analyse ist natürlich nicht vollständig, denn ich bekomme so nur die Benutzer. Es gibt durchaus andere Objekte, z.B. Gruppen und insbesondere Exchange Kontakte, die so nicht aufgelistet werden. Gänzlich unberücksichtigt sind natürlich CloudOnly-Benutzer und Gastkonten, die es sowieso nur in der Cloud gibt. Wer solchen Code automatisiert laufen lassen will, sollte eine App-Registration anlegen und keine interaktive Anmeldung nutzen. Ein Beispiel dazu finden sie auf Get-O365Usage und EXO PowerShell Automation. Die Nutzung der Exchange Online Powershell kann ebenfalls eine gute Quelle sein, wenn ihr Fokus auf einem Vergleich der GAL ist. Eine fertiges Skript finden Sie dazu auf Compare-GAL.

Reparieren

Eine pauschale Antwort und Schritt-für-Schritt-Anleitung kann es nicht geben, denn es gibt sehr viele Szenarien. Aber es gibt verschiedene Schritte, die unterschiedlich schwer und eingreifend sind.

  • Entra ID Connect Fehlersuche
    Der erste Schritt ist ein Blick in die Entra ID Connect Synchronisationsmanager. Laufen denn die Import, Sync, Export-Prozesse und sind diese Fehlerfrei? Vielleicht ist das lokal gelöschte Konto in Entra ID noch vorhanden, weil Entra ID-Connect einfach nicht mehr funktioniert. Es könnte an einen Windows Update oder Entra ID Connect Update gelegen haben, welches die Funktion stört. Auch kann die Kommunikation zur Cloud aufgrund von Änderungen in der Firewall oder dem HTTP-Proxy (Stichwort TLS 1.2 Enforcement) gestört sein. In dem Zug kann ich auch im Metaverse mal schauen, was der Stand des fraglichen Objekts ist, d.h. wird es noch von zwei Connectoren bedient.
  • Manchmal hilft ein „FullSync“
    Der regelmäßige Delta-Sync kann nicht alle Sonderfälle abdecken, insbesondere Änderungen an den Synchronisationsregeln fallen darunter. Nicht umsonst startet Entra ID Connect einen Full Sync, wenn Sie über den Assistenten z.B. die Auswahl der OUs oder andere Einstellungen ändern. Ein FullSync dauert zwar etwas, aber löst oft schon Unstimmigkeiten im Abgleich
  • Manuell löschen
    Wenn Objekte nicht mehr erforderlich sind aber weiter vorhanden sind, können Sie diese manchmal manuell löschen. Wenn z.B. ein AD-User gelöscht wurde aber in Entra ID das Objekt verbleibt, dann könnte es "disconnected" sein. Sie können in der Cloud einfach auch ein DirSync-Objekt in den Papierkorb löschen. Wenn es beim nächsten Sync wieder zurückkommt, dann hat es aber Entra ID Connect wieder hergrstellt, weil es lokal das Konto noch gibt oder Entra ID Connect in seinem Metaverse die Information noch hat.
  • Rematch und erneut löschen
    Entra ID Connect erlaubt ein "Hard-Match" und ein "Soft-Match". Sie können lokal das gelöschte Konto wieder herstellen (AD Papierkorb, Backup) oder neu anlegen und die ImmutableID entsprechend füllen, damit Entra ID Connect das Cloud-Objekt mit dem lokalen Objekt wieder verknüpft. Wenn sie dann das temporäre lokale Objekt löschen, sollte Entra ID Connect auch das Cloud Objekt in den Papierkorb verschieben.
  • Remove-ADSyncToolsAadObject
    Wenn die Fehler in Entra ID Connect und seiner Datenbank liegen, dann können Sie, vergleichbar zu ADSIEDT, natürlich direkt am Connectorspace und Metaverse operieren und Objekte entfernen. Das ist dann aber schon anspruchsvoller und sollte erfahrenen Administratoren oder Consultants vorbehalten bleiben.
  • Entra ID Connect Neuaufbau
    Wenn alles gefühlt nichts hilft und sie ziemlich sicher sind, dass irgendwas in Entra ID Connect durcheinander und nicht korrigierbar ist, dann kann eine Neuinstallation helfen. Beim ersten Lauf versucht Entra ID Connect einen "Hard Match", indem es erst alle Objekte aus dem lokalen AD und Entra ID importiert und dann anhand des Source Anchors ein Match herstellt. Das "sollte" immer funktionieren. Allerdings löst dies nicht das Problem überzähliger Objekte in Entra ID, die weiter bestehe bleiben. Zudem sollten Sie eine Dokumentation ihrer aktuellen Entra ID Connect-Konfiguration haben, damit Sie wirklich wieder alle OUs einschließen und ggfls. geänderte Synchronisationsregeln und andere Anpassungen identische abbilden.
  • DirSync Neuaufbau
    Der Vollständigkeit halber können Sie natürlich auch alles "zurückbauen", d.h. Entra ID Connect deinstallieren und den Tenant wieder DirSync-deaktivieren (Siehe Dirsync aus- und einschalten). Wenn Sie danach die Identitäten im Tenant und lokalen AD wie gewünscht bereinigt haben, können Sie den Verzeichnisabgleich wieder unter Nutzung der Hard-Match oder Soft-Match-Methode wieder herstellen.

Bei all den Reparaturmöglichkeiten sollten Sie nie vergessen, dass ihr Problem ja auch eine Ursache hat und solange Sie die Ursache nicht gefunden und beseitige haben, kann das Problem wieder kommen. Es sollte nicht zum Regelfall werden, dass Sie etwas hart fixen, was vorher an einer vermeidbaren Stelle falsch gemacht wurde.

Weitere Links