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
- Deleting a Connector Space: When, Why
and How
https://blogs.msdn.microsoft.com/connector_space/2014/10/15/deleting-a-connector-space-when-why-and-how/ - Using connectors with the Azure AD
Connect Sync Service Manager
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-sync-service-manager-ui-connectors - FIM Reference: Things to Look at before
Deleting a Connector Space
https://social.technet.microsoft.com/wiki/contents/articles/4189.fim-reference-things-to-look-at-before-deleting-a-connector-space.aspx