Zusammenführen von zwei AD-Strukturen, Teil 1

In den heutigen Tagen ist es durchaus üblich, dass Unternehmen sich zusammenschließen oder dass eine Firma eine andere aufkauft. So kann es durchaus sein, dass sich ein Administrator, der für das Active Directory (AD) sowie für den Betrieb der Exchange-Umgebung zuständig ist, eines Tages mit der Aufgabe konfrontiert sieht, die beiden ADs und die Mail-Umgebung von zwei Unternehmen zusammenzuführen.

In dieser zweiteiligen Beitragsreihe werden die wesentlichen Details eines AD- und Exchange-Mergers gezeigt. Dabei werden in einer Testumgebung die nötigen einzelnen Schritte ausgeführt. Wichtig ist dem Autor in erster Linie eine praxisbezogene Abwicklung: Die Quick Wins stehen dabei im Vordergrund. Denn nur so lassen sich aufwändige und komplexe Migrationen im laufenden Betrieb sicher durchführen.

Die hier demonstrierte Vorgehensweise sind nicht die einzigen Lösungsmöglichkeiten für diese Aufgabenstellung. Zudem wird eine jede Migration beziehungswiese jeder Merger seine eigenen Umgebungsbedingungen haben und sich daher unterscheiden.

Anders ausgedrückt: Keine Migration wird einer anderen komplett gleichen. In diesen beiden Beiträgen wird eine Migration in einer Testumgebung aufgesetzt, damit gewissermaßen eine Art Skizze entsteht. So wird die Vorgehensweise aber auch die nötigen Tools gezeigt, die für diese Aufgabe nötig sind. Somit bekommt der Administrator eine recht gute Vorstellung und wird so eine anstehende eigene Migration besser stemmen können.

Planung ist der Schlüssel zum Erfolg

Das Zusammenführen von zwei ADs an sich wäre gar nicht so schwer – doch gilt es, diese Aktion auszuführen, wenn das Netzwerk in Betrieb ist, wird sie deutlich schwieriger. Dabei lässt sich der Stellenwert einer detaillierten Planung gar nicht hoch genug einschätzen – vor allem wenn es sich um eine derart komplexe Angelegenheit handelt wie das Zusammenführen von zwei IT-Abteilungen.

Wer zu wenig Aufwand in die Planung steckt, der wird dann später die Zeche dafür präsentiert bekommen. Zu den wichtigen Punkten, die es im Vorfeld zu klären gilt, gehören:

•    Das Training für die Techniker, die die Migration beziehungsweise den  Merger ausführen,
•    die geplanten Ausfallzeiten für die IT-Ressourcen,
•    die kulturellen Unterschiede der beiden Unternehmen (sie zeigen sich zum Beispiel darin, wer Zugriff auf das AD und auf die Exchange-Umgebung bekommt oder auch wie die Sicherheitseinstellungen für die Dateien definiert sind),
•    die Netzwerkunterschiede zwischen den beiden Standorten,
•    Anomalien beim Netzwerk, beim AD und bei Exchange sowie
•    die Kommunikation zwischen Kunden und Angestellten.

Für das folgende Szenario übernimmt eine größere Firma – sie trägt die Bezeichnung New.com beziehungsweise New.local – ein kleineres Unternehmen (das soll Old.com oder Old.local benannt sein). Zudem sei angenommen, dass die für das Netzwerk verantwortlichen Techniker sämtliche Verbindungsprobleme bereits gelöst haben.

Somit sei bereits entweder eine standortübergreifende VPN-Lösung (Virtual Private Network) oder eine MPLS-Verbindung (Multiprotocol Label Switching) beziehungsweise irgendeine andere sichere Verbindung hergestellt. Alle weiteren Ausführungen funktionieren nur, wenn eine derartige, sichere Verbindung zwischen den Standorten besteht.

Schnelle Erfolge zuerst realisieren

Das Zusammenführen eines AD und der Exchange-Struktur kann in der Planungs- und Umsetzungsphase insgesamt mehrere Monate andauern. Dieser Zeithorizont wird der Unternehmensführung in der Regel nicht gut gefallen. Denn auch andere Unternehmensbereiche müssen ihr Business zusammenlegen – da kann es schon sein, dass die IT-Bereiche sich als Flaschenhals erweisen.

Um einen möglichst weichen und trotzdem zügigen Übergang zu schaffen, sollten im IT-Bereich die vergleichsweise einfachen Dinge zuerst erledigt werden – damit entsteht allein schon der Eindruck im Unternehmen, dass das kombinierte Unternehmen weitgehend funktioniert.

Ein Unternehmen – eine Mail-Infrastruktur

Eine schnelle Methode, um den Rest der Welt zu signalisieren, dass die beiden Unternehmen schon vereint sind, dreht sich um die E-Mail-Infrastruktur. Wenn alle Mitarbeiter dasselbe Mail-Suffix – wie etwa @new.com – in ihrer Mail-Adresse haben, besteht dieser Eindruck recht schnell. Von Microsoft gibt es einen detaillierten Artikel (How to Share an SMTP Address Space in Exchange 2000 Server or in Exchange Server 2003), der genau erklärt, wie eine Empfänger-Richtlinie aufgesetzt wird, wie ein neuer SMTP-Virtual-Server in der Exchange-Organisation angelegt wird und wie mit den Kontakten umzugehen ist. Danach sieht es für die externen wie auch für die internen Anwender aus, als wäre nur mehr ein Mail-System am Arbeiten.

Um eine ähnliche Struktur in einer Exchange-2007-Umgebung aufzusetzen, gibt es ebenfalls einen Beitrag: How to Configure Exchange 2007 to Route Messages for a Shared Address Space.

Die E-Mail für News.com läuft immer noch an den bestehenden Mail-Server im Hauptquartier von New.com. Die Konstellation zeigt Abbildung 1. Wenn nun eine Nachricht für einen Mitarbeiter von Old.com an einer New.com-Adresse eintrifft,  leitet der Exchange Server diese Mail an die Old.com-Adresse weiter.

Wenn nun ein Mitarbeiter von Old.com eine Nachricht versendet, stammt die primäre Adresse (sprich die Reply-to-Adresse) von new.com. Der Administrator wird bestimmt alle Mail-Adressen in einer einzigen Exchange-Organisation zusammenfassen. Doch dieser beschriebene Trick verschafft einem zumindest ein größeres Zeitfenster für die Umstellung.

Frei oder Belegt?

Das Zusammenführen zweier Unternehmen erfordert eine umfassende Kommunikation zwischen den beiden Unternehmen. Damit wird eine Vielzahl von Meetings die Folge sein. Leider haben geteilte Exchange-Umgebungen standardmäßig keinen gegenseitigen Durchgriff auf die Kalenderfunktion oder den Zugriff auf die Frei/Belegt-Funktion.

Wenn es nun gelingt, die Frei/Belegt-Information zwischen den beiden Hälften des Unternehmens bereitzustellen, lässt sich ein zweiter schneller Erfolg realisieren. Microsoft bietet ein frei verfügbares Tool namens InterOrganization Replication Tool. Es repliziert die öffentlichen Ordner mit der Frei/Belegt-Information. Das Werkzeug ist aber nicht Cluster-fähig – schlimmer, es lässt sich sogar durcheinanderbringen, wenn es auf einem Cluster-Knoten zum Einsatz kommt.

Wenn Exchange auf einem Cluster-Knoten läuft, braucht man noch einen alleinstehenden Exchange-Server für diese Replikation. Dabei ist aber bei den Einstellungen für den Benutzernamen und das Kennwort zu beachten, dass vor dem Benutzernamen noch der Domänenname angegeben wird:

DOMAIN\USERNAME

Die Frei/Belegt-Informationen, die zwischen zwei Exchange-Organisationen repliziert werden, können aber bis zu 30 Minuten alt sein. Dieses Wissen muss unbedingt bei den Anwendern ankommen. Das Tool selbst kommt in zwei Teilen: Einmal das Programm Replication Configuration und zum zweiten der Replication-Dienst. Der Microsoft-Beitrag „Installing, configuring, and using the InterOrg Replication utility“ zeigt Schritt für Schritt, wie man dieses Tool einsetzt.

Vertrauensstellungen gehören eingerichtet

Die Unternehmensführer müssen Daten untereinander teilen können – Dokumente wie Tabellenkalkulationen, Präsentationen und so weiter – und zwar auf eine sicher Art und Weise, sprich nicht nur über das Versenden von E-Mails. Die lässt sich recht einfach realisieren, wen erst einmal die Domänen in eine zusammengeführt sind. Doch es ist eine Lösung nötig, die sich um diese schnelle Anforderungen kümmern. Damit ein Benutzer aus einer Domäne Zugriffsrechte auf die Ressourcen einer anderen Domäne bekommt, muss man eine Gesamtstruktur (sprich einen Forest) aufsetzen und dann entsprechende Vertrauensstellungen einrichten.

Es lassen sich bestimmt in der jeweiligen Konstellation noch weitere schnelle Erfolge definieren und umsetzen. Dazu müssen die Migrations-Verantwortlichen die Anforderungen der einzelnen Abteilungen bestimmen – und dazu das Gespräch mit den Business Units suchen. Insgesamt verschaffen einem derartige schnelle Erfolge weitere Zeitspannen, um den kompletten Übergang hin zu bekommen.

Die Konzentration auf die Migration

Sobald die dringlichsten Aktionen ausgeführt und so die primären Anforderungen des Unternehmens abgedeckt sind, wird es Zeit, mit dem detaillierten Plan für die Umstellung von AD und Exchange-Umgebung zu beginnen. Wenn es nur wenige Benutzer, Arbeitsplatzsysteme und Server geht, kann man diese Objekte recht einfach der Domäne hinzufügen. Dazu eignen sich etablierte Tools wie zum Beispiel bereits vorliegende Skripts.

Doch wenn es um größere Konstrukte geht, empfiehlt sich das Suchen nach Tools von Drittherstellern. Hersteller wie Netiq und Quest habe Produkte im Portfolio, die einem bei der Migration helfen und die den Vorgang sogar modellieren können.

Von Microsoft gibt es das Active Directory Migration Tool (ADMT), das für geringere Anforderungen ausreichen kann. Die Version 3.1 des ADMT unterstützt auch 64-Bit-Umgebungen. Zu finden ist dieses Tool im Microsoft Download Center. Der Exchange Server verfügt über ein Werkzeug, das die Postfächer verschieben kann. Doch auch hier haben Dritthersteller eigene Werkzeuge im Programm.

Für den restlichen Beitrag werden allerdings der Rückgriff auf ADMT und der Einsatz der Standard-Tools von Exchange beschrieben. Die grundlegenden Konzepte sollten aber weitgehend identisch sein, selbst wenn man auf ausgetüftelte Tools zurückgreift.

Die Historie der SID

Wenn sich der Umzug aller Objekte in die neue Domäne nicht binnen weniger Stunden erledigen lässt, ist man gut beraten, die Migration in mehrere Stufen aufzuteilen. Dabei verbleiben einige Benutzer und Systemprozesse in der alten Domäne, wogegen andere bereits in die neue verschoben sind. Bei der Migration von Benutzern und Gruppen wird nur der Name des Objekts in die neue Domäne kopiert.

Die Objekte selbst werden aber dort komplett neu angelegt. Dabei bekommen sie auch die neue SID aus der neuen Domäne zugewiesen. Diese Situation führt unter Umständen zu einigen Problemen, wenn die migrierten Benutzer noch auf Ressourcen zugreifen müssen, die sich immer noch in der alten Domäne befinden. Denn dort sind die neuen SIDs nicht bekannt.

Eine mögliche Lösung für diese Herausforderung ist der Einsatz von SID History. Im Bild 2 wird gezeigt, wie ein Benutzer aus der Domäne New.local, der aus der Domäne Old.local stammt, zwei SIDs besitzt – die neu erzeugte für die Domäne New.local und die alte aus der Domäne Old. Das ist nun ein Attribut in SID History.

Wenn ein Benutzer auf eine Ressource in der Domäne Old zugreift, findet der Dateiserver die SID aus der Domäne old.com. Damit bekommt der Benutzer den Zugriff eingeräumt. Um die Funktion der SID History nutzen zu können, muss man das SID Filtering zwischen den Domänen ausschalten. Damit kann die SID des Objekts in die neue Domäne zusammen mit dem Objekt mit wandern.

Konfigurieren von Namensauflösung und Vertrauensstellungen

Danach wird es Zeit, sich um die eigentliche Abwicklung der Migration zu kümmern. Hier sollte der verantwortliche Administrator zuerst eine Testumgebung aufsetzen, damit er sich mit dem kompletten Setup-Prozess ohne großen Druck vertraut machen kann.

Der erste Schritt wäre dann das Einrichten einer Zweiwege-Vertrauensbeziehung zwischen den Domänen – denn nur wenn die besteht, kann man eine Migration ausführen. Diese Konfiguration der Vertrauensstellungen kann bereits früher erfolgt sein. Wenn sie noch nicht etabliert ist, muss es jetzt erfolgen.

Eine Vorbedingung für diese Aktion ist aber eine Eigenschaft: Beide Domänen müssen in der Lage sein, die FQDNs (Fully Qualified Domain Names) in der anderen Domäne auflösen zu können. Dazu muss man auf dem Reiter Weiterleitung (Forwarders) bei den Eigenschaften des DNS-Server die Eintragung machen, dass jede der beiden DNS-Domänen auf die andere verweist.

Bild 3 zeigt ein Beispiel, wie die Konfiguration aussehen muss, wenn die Maschinen in der Domäne New.local die Maschinennamen in der Domäne Old.local auflösen können. Ist diese Aktion abgeschlossen, sollte der Administrator den server1.old.local von jedem System aus in der Domäne New.local anpingen können.

Um eine Verbindung mit einem Hostnamen in der anderen Domäne herzustellen und dabei keinen FQDN zu verwenden, muss man beide Domänen (also new.local und old.local) in den erweiterten TCO/IP-Einstellungen auf jedem System eintragen. Diese Aufgabe händisch auszuführen  ist langatmig – daher sollte man dazu die Gruppenrichtlinien verwenden.
Mit dem Snap-in AD Domänen und Vertrauensstellungen kann der Administrator die Zweiwege-Vertrauensstellung zwischen den beiden Domänen einrichten. Dazu sind die folgenden Schritte nötig:

1. Zuerst muss er sich an einem Domänencontroller (DC) in einer der beiden Domänen anmelden – auf welcher ist nicht wichtig – und dort das Snap-in starten.
2. Mit einem rechten Mausklick auf die Domäne ist auf deren Eigenschaften zu gehen.
3. Auf dem Reiter zu den Vertrauensstellungen (Trusts) ist Neue Vertrauensstellung (New Trust) und dann Weiter anzuklicken.
4. Dann gilt es den FQDN der anderen Domäne einzutragen. Das ist auch der Grund, warum zuvor die DNS-Weiterleitung funktionieren muss.
5. Beim Typus der Vertrauensstellung ist Zweiwege (Two-way) anzugeben.
6. Danach soll diese Einstellung für beide Domänen (die lokale und die andere) auf der „Sides of Trust-Seite angegeben werden, damit diese Vertrauensstellung für beide Domänen gleichzeitig erzeugt wird.
7. Dann ist der Benutzername und das Kennwort des Administrators für die andere Domäne anzugeben. Mit einem Klick auf Weiter geht es zum Abschlussdialog.
8. Hier kann der Administrator alle Einstellungen nochmals prüfen und dann auf Weiter klicken.
9. Mit einem Klick auf Ja wird dann bestätigt, dass die ausgehende Vertrauensstellung und dann mit einem weiteren Ja dass die eingehende Vertrauensstellung eingerichtet wird. Danach sollten die Vertrauensstellungen wie gewünscht funktionieren.
10. Im letzten Schritt muss der Administrator dann noch bestätigen, dass das SID-Filtering zum Einsatz kommt. Diese Einstellung wird zu einem späteren Zeitpunkt dann deaktiviert.

Password Export Server einstellen

Das ADMT kann neue, komplexe Kennworte für die migrierten Benutzer erzeugen. Doch diese Informationen müssen dann auf eine möglichst sichere Art und Weise an die jeweiligen Benutzer verteilt werden. Daher könnte man sich auch überlegen, die bestehenden Kennwörter aus der alten Domäne in die neue Domäne mit zu nehmen – das wird in der Regel für alle Beteiligten die einfachere Lösung sein.

Wer keine Kennwörter über das Netzwerk übertragen möchte, der kann sich darauf verlassen, diese Informationen beim Weg über die Leitung zu verschlüsseln. Zudem kann man auch vorgeben, dass die Benutzer nach der ersten Anmeldung ihr Kennwort ändern müssen. Für diese Aufgabe sind die folgenden fünf Schritte zu absolvieren:

1.    Zuerst muss man sich als Domänen-Administrator auf dem Computer anmelden, auf dem das ADMT installiert ist.

2.    Auf der Kommandozeile ist das folgende ADMT-Kommando einzugeben, um die .pes-datei zu erzeugen:

admt key /opt:create /sd:old /kf:c:\

3.    Dann muss der Administrator die eben erzeugte .pes-Datei auf einen Dc in der Ausgangsdomäne (also old.local) kopieren.

4.    Die Password-Migration-DLL muss auf dem Password Export Server (PES) installiert werden. Dazu muss man pwdmig.msi starten. Der PES steht ebenfalls kostenlos über das Microsoft Download Center zur Verfügung.  Es muss darauf geachtet werden, dass man PES von ADMT 3.1 verwendet, wenn es sich um 64-Bit-DCs handelt. Die Installation von PES geht recht schnell über die Bühne und fragt auch nach der zuvor erstellten .pes-Datei.

5.    Dann muss man noch angeben, dass der Password Export Server Dienst als ein Benutzer mit Domänenadministrator-Privilegien läuft. Dabei ist das Format domain\account zu verwenden.

Nach der Installation des PES-Dienstes ist der DC neu zu starten. Diese Ausfallzeit sollte man in seine Überlegungen vorab einbezogen haben. Standardmäßig ist der Starttyp für den PES-Dienst auf manuell eingestellt. Daher wird er beim Neustart des Servers nicht anlaufen. Um dies zu gewährleisten, muss in der Registry eine entsprechende Einstellung gemacht werden.

Der Wert für den Schlüssel (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPasswordExport) vom Typ DWORD muss auf 1 geändert werden. Aus Sicherheitsgründen empfiehlt Microsoft, dass man den PES-Dienst nicht aktiv hat und dass der entsprechende Schlüssel in der Registry den Wert 0 hat. Erst wenn man die Kennwörter migrieren will, sollte man diese Umstellung machen.

Weitere Informationen gibt der Microsoft-Beitrag „How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003“.

Deaktivieren des SID-Filtering

Damit die SIDs von Benutzern und Gruppen zwischen den beiden Domänen hin und her wandern können, muss die Sicherheitsfunktion des SID-Filtering in der Ausgangsdomäne abgestellt werden. Dazu muss der Administrator auf einem DC in der Domäne old.local den folgenden Befehl absetzen:

Netdom trust old /domain:new /quarantine:No /UserD:Administrator /passwordD:P@ssword

Dieser Befehl muss auf einer Zeile eingegeben werden (in der obigen Darstellung erfolgen automatische Zeilenumbrüche aufgrund der Layoutvorgaben). Ist das SID-Filtering ausgeschaltet, bekommt man eine Nachricht, dass die SIDs nicht länger gefiltert werden.

Hier ist auch noch darauf hinzuweisen, dass Netdom auf Servern mit Windows 2000 oder 2003 nicht standardmäßig installiert ist. Das Programm liegt auf dem Installationsmedium im Verzeichnis Support\Tools.

Erzeugen eines Migrations-Servers

Die Erfahrung hat dem Autor gezeigt, dass der Einsatz eines dedizierten Migrations-Servers die Aufgabenstellung vereinfacht. Dieses System muss nicht über großartige Ressourcen verfügen, es reicht eine einfache virtuelle Maschine mit Windows Server 2003 Standard. ADMT läuft nicht auf Windows XP. Dabei muss der Migrations-Server unbedingt ein Mitglied in der Zieldomäne (New.com) sein. Auch wenn es mittlerweile die Vertrauensstellung zwischen den beiden Domänen existiert, sollte sich der Administrator immer in der neuen Domäne anmelden, wenn er Objekte aus dem alten Verzeichnis in das neue migrieren möchte.

Es bleibt aber auch noch ein kleiner – aber umso wichtigerer – Schritt in der alten Domäne zu machen. Damit die Objekte in die neue Domäne migriert werden können: Ein Benutzerkonto für den Domänen-Administrator in der Zieldomäne muss in die Administratorgruppe in der Ausgangsdomäne eingetragen werden (siehe Bild 4).

Wenn man ADMT auf dem Migrations-Server installiert, stehen einem zwei Optionen für das Ablegen der Migrationsdaten offen: Man kann eine kostenlose SQL-Express-Datenbank für kleinere und einfache Migrationen einsetzen. Oder aber man entscheidet sich für die leistungsstärkere Version mit einem SQL Server. Diese Variante empfiehlt sich für größere und komplexere Projekte. Die Entscheidung sollte man nach den Randbedingungen der eigenen Aufgabenstellung treffen. Im weiteren Verlauf wird die einfachere Variante mit SQL Express gewählt.

Vorbereiten der Computer und der neuen Domäne

Der letzte Schritt in Sachen Vorbereitung der Umgebung für die Migration betrifft die einzelnen Computer: Sie muss für die Migration vorbereitet sein. Neuere Versionen von Windows verfügen über eine eingebaute Firewall, die Verbindungsversuche durch das ADMT blockiert. Die Ports, die ADMT verwendet, sind nicht gut dokumentiert. Jedoch kann man die Firewall komplett deaktivieren und zwar für die Zeitspanne, in der die Migration des Systems ausgeführt wird.
Das wird idealerweise mit Hilfe eines Gruppenrichtlinienobjekts (GPO) erledigt. Das GPO muss dazu die Firewall öffnen. Dieses GPO muss mit einer Organisationseinheit (OU, Organizational Unit) namens MigrationPrep verknüpft werden. Danach ist der zu migrierende Computer direkt vor der Migration in diese OU zu verschieben.

Der Benutzer, der die Migration ausführt, muss Administratorrechte auf jedem Computer besitzen, der migriert wird. Auch dazu eignet sich der Einsatz einer GPO, die mit der OU MigrationPrep verknüpft ist. Des Weiteren muss dieser Benutzer, der die Migration durchführt, auch noch das Recht haben, Computer der neuen Domäne hinzuzufügen.

In der Dokumentation zum SADMT, dem ADMT Guide von Microsoft, wird beschrieben, dass alle Ziel-Domänen entweder auf dem nativen Funktionsebene von Windows 2000, oder dem Windows Server 2003 Funktionslevel oder aber auf dem Windows Server 2008 Funktionslevel agieren. Dabei ist dieser Prozess nicht umkehrbar. Daher sollte man sich als Administrator über die Konsequenzen im Klaren sein – ehe man den Funktionslevel der Domäne heraufsetzt.

Um dieses Heraufsetzen zu erledigen, muss der Administrator das Snap-in AD Benutzer und Computer starten, einen rechten Mausklick auf die Domäne (new.local) ausführen und dort aus dem Menü den Domänen-Funktionslevel hochsetzen. Dabei ist zum Beispiel Windows Server 2003 im folgenden Dialog anzugeben.

Vorbereitung ist die Basis für den Erfolg

Allein schon die Vorbereitungen für das Zusammenführen von zwei Domänen ist eine große Herausforderung. Daher wird sich der Administrator selbst einen großen Gefallen tun, wenn er diese Aktionen in einer Testumgebung ausprobiert – ehe er daran geht, diese Umstellung in der Produktivumgebung auszuführen. Im zweiten Teil dieses Beitrags geht es um die Frage, wie Benutzer, Computer und Gruppen in die neue Domäne migriert werden. Zudem wird der Bereich der Exchange-Umgebung gezeigt.

Eric B. Rux/rhh