ADSync und DN-Änderungen

Achten Sie auf Besonderheiten, wenn sie eine OU im lokalen AD einfach umbenennen. Der Verzeichnisabgleich mit Office 365 kann darüber stolpern.

Auslöser

Auch in der kleinsten Firma werden immer mal Abteilungen umbenannt, Benutzer verschoben oder heiraten oder OU-Strukturen verändert. Damit haben wir mehrere Szenarien, auf die ADSync korrekt regieren muss. Und damit meine ich nicht nur das große Problem, wenn Sie OUs als Filterkriterium nutzen und durch die Änderung sich deren Scope verändert. Folgende Testfälle habe ich mir angeschaut

  • Benutzer ändert Name
    Wenn der Name Teil des DN ist, dann ändert sich der relative Anteil (RDN) und damit auch der DN
  • Benutzer wird verschoben
    In dem Zuge ändert sich ein Zwischenstück der DN.
  • OU wird umbenannt
    In dem Zuge ändert sich bei sehr vielen Benutzern der DN

Die Sonderfälle, dass durch diese Änderung ein Objekte aus dem Synchronisationsblockfeld von AADConnect raus- oder hineinfällt, betrachte ich nicht weiter, da für ADSync das dann entweder ein "neues" Objekt, welches initial synchronisiert wird oder eben als gelöscht angesehen und auch in der Cloud entfernt wird.

Was macht ADSync draus?

Ich habe daher in meiner Umgebung eine kleine Test-Umgebung angelegt.

carius.de/DNTEST/OU1/User1  Benutzer wird umbenannt
carius.de/DNTEST/OU2/User2  OU wird umbenannt
carius.de/DNTEST/OU3/User3  Benutzer wird in OU4 verschoben
carius.de/DNTEST/OU4        OU ist das Ziel für User3

Danach habe ich ADSync mit "Start-ADSyncCycle" zweimal gestartet. Er hat natürlich die Benutzer erst in seinen Connector-Space übertragen und dann über das MetaVerse in meinen Tenant exportiert. Es waren also 8 neue Objekte im AD zum Metaverse aber nur die drei Benutzer sind auch im AzureAD gelandet:

 

Beim zweiten Lauf hat AADConnect dann die erforderlichen Updates in das lokale AD geschrieben. Mein Get-ADChanges zeigt, dass nur das Feld "ms-ds-consistencyguid bei den Objekten aktualisiert wurde.

Erst jetzt ist der Sync komplett. Im Connector Space des AD sehen Sie dann alle 8 Elemente

Beim Benutzer User 1 sieht der Inhalt des Connectorspace im AD und AzureAD allerdings unterschiedlich aus:

Im AzureAD gibt es ein Feld "On-PremisesDistinguishedName. Bei allen drei Objekten sind die Werte ähnlich

Rename - OK

Ich habe dann ADSync kurz pausiert und die drei Objekte verändert.

DN-Alt DN Neu Beschreibung

carius.de/DNTEST/OU1/User1

carius.de/DNTEST/OU1/User1Neu

Benutzer wird umbenannt

carius.de/DNTEST/OU2/User2

carius.de/DNTEST/OU2Neu/User2

OU wird umbenannt

carius.de/DNTEST/OU3/User3

carius.de/DNTEST/OU4/User3

Benutzer wurde in OU4 verschoben

Im lokalen Active Directory sieht das dann so aus:

Auf den ersten Blick erscheint Fall 2 und 3 identisch zu sein, aber für AADConnect ist es schon ein Unterschied, ob sich die OU verändert aber die interne ObjectGUID etc gleich bleibt oder ob der Benutzer von einer OU in eine andere OU verschoben wird.

Danach habe wieder ADSync mit "Start-ADSyncCycle" zweimal gestartet. Beim ersten Lauf hat die Änderungen im lokalen AD erst mal erkannt.

Das sehen wir dann auch im ADSync-Protokoll. Ich vergleiche dann auch alle anderen Konten und die Einstellungen passen alle.

Writeback

Die ganz Seite ist aber ja nicht entstanden, weil alles geht sondern eher, weil genau ein Fall "Rename einer OU" in einer produktiven Umgebung aufgetreten ist und danach ADSync sich mit Fehlern gemeldet hat. Er konnte nämlich eine Änderung in der Cloud, die durch Windows Hello verursacht wurde, nicht in die lokale Umgebung zurück schreiben. Die Fehlermeldung war dahingehend verwirrend, da ADSync das Objekt anhand des alten DN weiter gesucht hat.

Die Fehlermeldung "dn-attributes-failure" mit dem Hinweis aus "The name reference is invalid" zeigt hier an, dass im Connector-Space zum Active Directory diese Änderung des DN nicht korrekt übernommen wurde. Sobald nun eine Änderung im AzureAD zurückgeschrieben werden sollte, kann ADSync das Objekt anhand des alten DN nicht finden und wirft diesen Fehler.

Die Lösung war in dem Fall, den kompletten Connector Space auf dem Connector zu löschen. Dazu gehen Sie erst auf "Connectors" um dann auf dem Connector über das Kontext-Menü den "Delete" zu starten.

Damit löschen Sie nicht sofort den Connector sondern im nächsten Dialog wählen Sie natürlich nur "Connector Space" aus. Danach sollten Sie manuell einen "Full Import" und einen "Full Sync" machen, bei dem Sie die Aktionen genau beobachten, damit der Neuaufbau diesmal besser passt.

Nachdem ich so mein Problem gelöst habe und die Zuordnung der Konten über einen JOIN neu erfolgt ist, konnte ich natürlich nicht mehr weiter die Ursache untersuchen. Der alte Connector Space war ja nun wer, was so auch bei dem Versuch einer Analyse angezeigt wurde.

Ursächlich war auf jeden Fall eine Umbenennung von OUs im Active Directory, die in Verbindung mit einem Zurückschreiben in das lokale Active Directory diesen Konflikt erzeugt hat.

Eventlog

Wohl dem, der seinen ADSync regelmäßig überwacht. Hier hat der folgende Eventlog-Eintrag schon mal einen Hinweis gegeben.

Log Name:      Application
Source:        ADSync
Date:          21.02.2019 03:36:15
Event ID:      6127
Task Category: Management Agent Run Profile
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      DS1.msxfaq.de
Description:
The management agent "msxfaq.de - AAD" completed run profile "Delta Synchronization" 
with a delta import or delta synchronization step type. 
The rules configuration has changed since the last full synchronization.
 
 User Action
 To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.

Die Export-Fehler waren dann etwas später zu finden:

Log Name:      Application
Source:        ADSync
Date:          22.02.2019 11:03:49
Event ID:      6100
Task Category: Management Agent Run Profile
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      DS1.msxfaq.de
Description:
The management agent "msxfaq.de" step execution completed on run profile "Export" with errors.
 
 Additional Information
 Discovery Errors       : "0"
 Synchronization Errors : "0"
 Metaverse Retry Errors : "0"
 Export Errors          : "3"
 Warnings               : "0"
 
 User Action
 View the management agent run history for details.

Eine Überwachung auf EventID 6100 kann daher schon weiter helfen, damit sich solche Probleme nicht noch weiter verschlimmern.

Weitere Links