22. März 2016

On-Premise Active Directory Migration in einem Office 365 DirSync-Szenario

Im Zuge interner Umstrukturierungsmaßnahmen ergab sich die Notwendigkeit unsere on-premise Active Directory Domain in eine neue Domain zu migrieren. Dies stellt prinzipiell keine große Herausforderung dar. Neue AD Domain aufbauen, einen Two-Way Trust zwischen der alten und der neuen Domain herstellen und anschließend mit Hilfe von ADMT die gewünschten AD Objekte in die neue Domain migrieren...


Bei uns kam nun allerdings erschwerend hinzu, dass wir Office 365 einsetzen und eine Verzeichnissynchronisation zwischen unserer lokalen AD Umgebung und Azure AD bestand. Daraus ergaben sich die folgenden Anforderungen.

  • Sämtliche User Accounts sollten von der alten in die neue Domain migriert werden.
  • Die migrierten User Accounts sollten weiterhin hin zu Azure AD synchronisiert werden.
  • Die Verzeichnissynchronisation in der neuen on-premise Domain sollte die bereits vorhanden Azure AD Accounts aktualisieren.
Der naive Ansatz wäre jeweils in der alten und der neuen Domain einen Server für die Verzeichnissynchronisation bereitzustellen, anschließend die User Accounts per ADMT [1] zu migrieren und dann zu hoffen, dass die migrierten User vom Synchronisations-Server in der neuen Domäne sauber ins Azure AD synchronisiert werden.

Theoretisch ist dieser Ansatz nachvollziehbar, in der Praxis jedoch mit einigen Fallstricken verbunden.
  1. Die Nutzung von mehreren Synchronisations-Servern für einen Azure bzw. Office 365 Tenant wird von Microsoft nicht unterstützt und mit "...unexpected issues may occur..." kommentiert.
  2. Woher weiß die Verzeichnissynchronisation, dass der durch ADMT migrierte User nun auch wirklich der User aus der alten AD Domain ist? Schließlich ändern sich bei der Migration Attribute wie SID, objectGUID und userPrincipalName.
Bei der Recherche zu dem Thema stößt man unweigerlich auf den Begriff der ImmutableId. Kurz gesagt, die ImmutableId verknüpft ein lokales Benutzerkonto eindeutig mit einem Benutzerkonto in Office 365 bzw. Azure AD.

Die Verzeichnissynchronisierung verwendet standardmäßig die objectGUID des lokalen AD Accounts um die ImmutableId für ein Azure AD Konto zu erstellen. Dabei handelt es sich eigentlich nur um eine Base64-kodierte String-Repräsentation der objectGUID. Zum Glück lässt sich dieses, in der Synchronisation als sourceAnchor bezeichnete, Attribut ändern. Weitere Recherche führte dann zu [4] und der Idee, das im AD unbenutzte Attribut, mS-DS-ConsistencyGuid als sourceAnchor zu verwenden und bei migrierten Benutzerkonten mit dem alten Wert von objectGUID zu füllen.

Damit blieb an dieser Stelle nur noch offen, wie das Problem der zwei zu synchronisierenden AD-Domänen zu lösen war. Glücklicherweise war zu diesem Zeitpunkt Microsofts neueste Verzeichnissynchronisierungs-Software Azure AD Connect [5] offiziell verfügbar. Damit war es dann auch recht unkompliziert möglich, mehrere AD-Forests mit einem einzigen Sync-Server zu synchronisieren.

Zusammengefasst waren die notwendigen Schritte für unser Szenario:

  • Bereitstellen eines Synchronisierungs-Servers in der neuen Domäne.
  • Installation und Konfiguration von Azure AD Connect auf dem neuen Server.
    • mS-DS-ConsistencyGuid dabei als sourceAnchor wählen.
  • Sicherstellen, dass vor jeder Synchronisierung das Attribut mS-DS-ConsistencyGuid für jedes zu synchronisierende Benutzerkonto gesetzt ist.
  • Alten Synchronisierungs-Server abschalten.
  • Neue Synchronisierungs-Instanz starten.

Um sicherzustellen, dass unser gewähltes sourceAnchor Attribut auch immer gefüllt ist, wurde ein Skript benutzt, das vor jeder Synchronisierung in der alten und in der neuen Domäne geprüft hat, ob der sourceAnchor gefüllt ist und dann ggf. den Wert von objectGUID nach mS-DS-ConsistencyGuid kopiert hat. Dazu wurde einfach der, von Azure AD Connect angelegte, Scheduled Task um den Aufruf des Skripts erweitert.



Die angegebene Batch-Datei hat dann das eigentliche PowerShell-Skript aufgerufen:

powershell -NoLogo -File %~dp0CheckConsistencyGuid.ps1 "old.contoso.com" "new.contoso.com"

Das Skript selbst gibt es hier.

Damit konnten nun Benutzerkonten nahtlos von der alten in die neue AD Domäne verschoben werden, ohne das die Verknüpfung mit dem jeweiligen Office 365 Konto verloren ging.

Referenzen


[2] Windows Azure Active Directory Connector part 3: immutable ID: http://blog.msresource.net/2014/03/10/windows-azure-active-directory-connector-part-3-immutable-id/

[3] Revisiting the Microsoft Online immutable ID design decision: http://blog.msresource.net/2015/05/20/revisiting-the-microsoft-online-immutable-id-design-decision/

0 Kommentare: