AD-Reorg mit ADSync
Solange Benutzer, Gruppen und Computer in einem lokalen Active Directory angelegt sind und Firmen andere Firmenteile kaufen oder verkaufen wird es auch Migrationen und Umorganisationen geben. Damit verändern sich auch Objekte im Active Directory und insbesondere mit ADSync sollten Sie die Auswirkungen kennen. Diese Seite geht nicht auf die Migration von Benutzern zwischen Tenants ein.
ADSync und ADObjekte
Da ich die Funktionsweise auf anderen Seiten im Bereich Office 365 Identity Management ausführlich beschrieben habe, fasse ich mir als Einleitung kürzer:
- Active Directory und ADSync sind Standard
Wer heute ein lokales Active Directory hat, wird mit Office 365 auch ADSync einsetzen, um die Benutzer in der Cloud zu verwalten und vermutlich Kennworte mit Password Hash Sync (PHS) abzugleichen. - 99% Oneway
Die meisten Änderungen erfolgen im lokalen Active Directory und werden von ADSync in die Cloud übertragen - ADSync Matched
Konten ändern sich, d.h. einen Heirat ändert meist neben dem Nachname/Displayname auch den UPN, Mail und mehr. Damit ADSync das Objekt in der Cloud sicher zuordnen kann, nutzt ADSync die ObjectGUID und bei Benutzern seit längeren die msdsConsistencyGUID. Bei größeren Reorganisationen muss darauf geachtet werden, da ansonsten der Cloud-Benutzer samt Daten (Postfach, OneDrive etc.) gelöscht und neu angelegt wird - ADSync Filter
Ein Administrator kann ADSync mit Filtern steuern, nicht alle Objekte zu synchronisieren.
Diese Informationen erlauben und nun die nächsten Abschnitt zu verstehen.
Szenarien
Es gibt verschiedene Fälle einer Reorganisation, die wir in Verbindung mit Office 365 betrachten müssen:
Szenario | Beschreibung |
---|---|
Innerhalb der Domain |
Diese Aktion kann schon "aus Versehen" durch einen Administrator passieren, wenn er mit der MMC für Benutzer und Computer unvorsichtig arbeitet. Das größte Problem dabei könnte ein ADSync-Filter sein, so dass das verschobene Objekt nicht mehr durch ADSync importiert wird. Dann wird daraus ein "Delete" und der Benutzer verliert alle Funktionen in der Cloud. Eine Anpassung von ADSync, damit dieses Objekt wieder synchronisiert wird, löst das Problem umgehend, denn das Office 365-Objekt wird samt Postfach wieder hergestellt. Allerdings wurden die Mails, die in der Zwischenzeit eingetroffen sind, natürlich als unzustellbar abgewiesen. |
Innerhalb des Forest |
Mehrere Domänen im gleichen Forest kenne ich meist aus geografisch verteilten Firmen, die damals laut Microsoft Empfehlung pro Kontinent oder Land eine Subdomain unter einer Root-Domain aufgebaut haben. Bandbreite und WAN-Verfügbarkeit waren die Gründe. Einen Benutzer von einer Domäne in eine andere Domäne zu verschieben, ist mit ADMT oder MOVETREE möglich. Allerdings ändern sich einige AD-Felder wie z.B. die SID. Für eine funktionierende SID-History müssen ggfls. Trusts freigeschaltet werden und auch lokalen Benutzerprofile gehen ohne Vorkehrungen verloren. Der Trick besteht dabei, dass der "Source Anchor" mitgenommen wird und während der Verschiebung ADSync vielleicht nicht mit "halben Daten" arbeiten sollte. |
Zwischen Forests |
Mehrere Forests kommen bei Verkauf und Zukauf oder Konzernumbauten zum Tragen. Der Aufwand ist deutlich höher, da z.B. der UPN von zwei Forests nicht gleich ist und auch Gruppenmitgliedschaften nicht so einfach umgesetzt weiter genutzt werden können. |
Fremdsystem |
Ein Sonderfall ist eine Migration von einem Fremdsystem mit einem "CloudOnly"-Konto zu einem Active Directory. Hier kommt es dann aber mehr auf die Vorarbeiten an, damit das neue AD-Konto mit dem Cloud-Konto verbunden wird. |
AD-Felder
Abhängig vom Szenario verändern sich einige für Office 365 und ADSync essentielle Felder. Besonders kritisch sind.
-
ObjectGUID bzw. msdsconsistencyGUID
Bei einer aktiven ADSync-Konfiguration steht in diesem Feld der SourceAnchor des Cloud-Objekts. Wenn das Feld nicht übertragen wird, verliert ADSync die Verknüpfung und erkennt einen "Delete". Das Cloud-Konto wird dann "gelöscht", bis es wieder manuell oder durch ADSync zurückgeholt wird. - UPN
Der Anmeldenamen dient der Authentsifizierung an der Cloud und bei einer Migration in einen anderen Forest ist es knifflig den UPN beizubehalten, da eine UPN-Domain offiziell nur einem Forest zugewiesen werden kann. Ansonsten gibt es Probleme bei Trusts und z.B. PassThrough-Authentication oder ADFS
Die weiteren Felder sind für Office 365 ebenfalls wichtig aber unkritisch, da der Inhalt übernommen werden können. Office 365 und ADSync stören sich z.B. nicht am CN, DN, SamAccountname oder SID. Für die interne Migration ist es natürlich dennoch wichtig, weil lokale Dateiserver, Windows Profile und andere lokale Dienste damit verbunden sein könnten.
Feld | Innerhalb der Domain | Innerhalb des Forest | Zwischen Forest | Fremdsystem |
---|---|---|---|---|
Distinguishedname |
ändert sich |
Ändert sich |
Ändert sich |
Neu erstellt |
CommonName |
bleibt gleich |
kann gleich bleiben |
kann gleich bleiben |
Neu erstellt |
ObjectGUID |
bleibt gleich |
bleibt gleich |
ändert sich |
Neu erstellt |
SamAccountName |
bleibt gleich |
kann gleich bleiben |
kann gleich bleiben |
Neu erstellt |
SID |
bleibt gleich |
Neu + SID History |
Neu + SID History |
Neu erstellt |
UPN |
bleibt gleich |
bleibt gleich |
Neue Domain |
Neu erstellt |
msdsconsistencyGUID |
bleibt gleich |
bleibt gleich |
bleibt gleich |
Erstellt beim Match |
MemberOf |
bleibt gleich |
Abhängig von Gruppen |
Neu, ggfls. Trusts |
Neu erstellt |
bleibt gleich |
bleibt gleich |
kann übernommen werden |
Neu erstellt |
|
ProxyAddresses |
bleibt gleich |
bleibt gleich |
kann übernommen werden |
Neu erstellt |
msRTCSIP-PrimaryUserAddress |
bleibt gleich |
bleibt gleich |
kann übernommen werden |
Neu erstellt |
Kennwort |
bleibt gleich |
Kann kopiert werden |
Kann kopiert werden |
Neu erstellt |
Welches Feld nun für ihre Migration relevant ist, hängt auch von ihrer Konfiguration des ADSync ab. Früher hat ADSync einfach die ObjektGUID genutzt und die kann nur innerhalb des Forest bei entsprechender Migration des Objekts beibehalten werden. Nicht ohne Grund hat Microsoft ADSync mit der Version 1.1.553 und neuer auf das Feld msdsconsistencyGUID umgestellt, welches frei gesetzt werden kann und damit sogar Cross-Forest-Migrationen möglich sind.
Es gibt aber auch Firmen, die weder "ObjectGUID" noch "msdsconsistencyGUID" nutzen, sondern ein ganz eigenes Feld dazu definiert haben. Hier müssen Sie dann schauen, wie diese Information beim Umzug mit migriert wird.
Worauf zu achten ist
Bei einer Verlagerung eines Active Directory Benutzer Kontos in eine andere OU, eine andere Domäne oder gar einen anderen Forest müssen Sie für Office 365 und ADSync immer bedenken, was ADSync davon mitbekommt. ADSync liest regelmäßig die Informationen aus den verbundenen Verzeichnisdiensten aus, aktualisiert basierend darauf seine Metadatenbank und überträgt Änderungen zu dem Zielsystemen in der Cloud. Wenn Sie die Änderungen an der Quelle so aussehen lassen, dass ADSync in Richtung Cloud keine Änderung sieht, dann ändert sich nichts in der Cloud.
Entsprechend würde ich folgende Schritte einhalten, wenn Sie mit ADSync sowohl das aktuelle Quellobjekt als auch das zukünftige Zielobjekt abgleichen.
- ADSync anhalten
- Konteninformationen aus der Quelle auslesen und sichern
- Konto in der Quelle entfernen
- Konto im Ziel anlegen und Daten wieder
herstellen
Das gilt insbesondere für den SourceAnchor aber auch für Mail, ProxyAddresses, SIP-Adressen, Rufnummern, Gruppenmitgliedschaften, SIDHistory, Kennwort etc. Beim Umzug in einen anderen AD-Forest muss natürlich der UPN mit geändert werden, wenn Sie nicht mit Password Hash Sync (PHS) arbeiten - AD-Replikation abwarten
Sowohl in der Quelle als auch Ziel müssen die Änderungen sicher auf den DCs angekommen sein, die von ADSync genutzt werden - ADSync starten
Hier sollten Sie nun zuerst den Import und Sync der Quelle anstoßen, damit das Objekt im Metaverse löscht wird. Dann kommt der Import und Sync aus dem Ziel, damit das Objekt im Metaverse wieder gematched wird. Beim Export in die Cloud sollte sich dann nichts wesentliches geändert haben.
Ein Sonderfall ist eine Verschiebeaktion innerhalb eines Forest, da hier die Schritte 2-4 mit dem richtigen Werkzeug (ADMT, MoveTree) zusammengefasst werden können und es keine Doppelung gibt.
Wenn Sie ADSync nicht stoppen, dann kann es natürlich passieren, dass das Objekte in der Quelle schon weg ist aber im Ziel noch nicht komplett angelegt wurde. Es könnte daher passieren, dass ADSync erst einen "Delete" erkennt und das Objekte auch in der Cloud entfernt. Beim nächsten Lauf würde das Objekt aber wieder reaktiviert und das ADSync über den SourceAnchor auch das in der Cloud "gelöschte Objekt" wieder findet, wird es wieder hergestellt. Es ist in der Zeit aber z.B. nicht per Mail erreichbar.
Sie sollten auch vermeiden, dass das Objekt "doppelt" vorkommen. Sie können ADSync natürlich so einrichten, dass er doppelte Objekte zusammenführt. Das Thema kennen wir schon beim Einsatz von Ressource Forests mit Exchange. Bei ADSync müssen Sie diese Einstellung dann aber auch entsprechend konfigurieren.
Das ist aber nicht der Regelfall und auf Dauer würde ich darauf verzichten, doppelte Konten zu betreiben. Das bedeutet natürlich, dass Sie mit Trusts und SID-History ggfls. die Zugriffe auf früher genutzte Dienste bereitstellen müssen. Aber das kennen erfahrene Administratoren ja schon aus den On-Premises-Zeiten mit ADMT -Active Directory Migration Toolkit und Co
Ich habe noch nicht alle Dienst in der Cloud verifiziert, ob so ein wieder hergestelltes Objekte komplett alle Rechte und Mitgliedschaften, z.B. in Office Groups, Microsoft Teams, Power Automate, Azure Subscriptions und Resources u.a. wieder erlangt.
Weitere Links
- Move-ADObject
- Office 365 Identity Management
- SourceAnchor und ADMT
- Password Hash Sync (PHS)
- ADMT -Active Directory Migration Toolkit
- Org2Org Basics
- "Der Wert von msRTCSIP-PrimaryUserAddress oder die SIP-Adresse im Feld
proxyAddresses in Ihrem lokalen Active Directory ist nicht eindeutig" im Office
365 Portal
https://docs.microsoft.com/de-de/skypeforbusiness/troubleshoot/online-configuration/msrtcsip-primaryuseraddress-proxyaddaddress