Hin zum Active Directory

Eine Active-Directory-Migration ist meist mit einem relativ hohen Aufwand verbunden. Deswegen fragen sich viele Projektmanager, wie sich diese Umstellung überhaupt rechnen kann und wie sie dies der Geschäftsleitung vermitteln können. Die Stärken des Active Directory müssen deshalb zunächst genau analysiert und mit der bestehenden Struktur verglichen werden. In den meisten Fällen spielen folgende Gründe für eine Migration die Hauptrolle:

• es bestehen zu viele Domänen, und es ist aufwendig, die Kontrolle zu behalten;

• die administrative Struktur ist gewachsen und zu viele Benutzer (und Administratoren) besitzen zu hohe Berechtigungen;

• Windows-XP- oder -2000-Clients können ohne Active Directory nicht gut gesteuert werden;

• andere Anwendungen wie beispielsweise Exchange 2003 erfordern für die Einführung eine Active-Directory-Umgebung.

Design

Zu Beginn der Active-Directory-Einführung steht die Designphase. Hier wird der Zielzustand diskutiert, getestet und festgelegt. Diese wichtige Projektphase ist nicht zu unterschätzen, da hier das Fundament für die Implementierung gelegt wird. Schon hier sollten einige alte Zöpfe abgeschnitten werden, an die sich einige Administratoren gewöhnt haben. Ebenfalls müssen die Verantwortlichen von schon bestehenden DNS-Diensten involviert werden. Meist stellt sich diese Diskussion als sehr schwierig dar, da hier oft Unix-Administratoren am Tisch sitzen, die Microsoft-DNS-Implementierungen skeptisch gegenüberstehen.

Update oder Migration

Sind alle diese organisatorischen und politischen Themen erfolgreich gemeistert, muss entschieden werden, wie der Übergang zum Active Directory erfolgen soll. Zwei Alternativen sind in der Praxis denkbar: Eine relativ einfache Aktualisierung der Domäne(n) oder eine aufwendigere Migration. Abhängig von der gewünschten Zielstruktur wählt man die bessere Lösung. Das typische Migrationsszenario wird dann gewählt, wenn mehrere Domänen zusammengefasst und damit konsolidiert werden sollen. Ein Update bietet sich bei einfacheren Strukturen an.

Update

Ein Update beginnt immer beim primären Domänencontroller (PDC) der NT4-Domäne. In der Praxis wird dazu oft eine temporäre Hardware herangezogen. Dieser PC (ein einfacher Desktop-Rechner) wird als Backup-Domänencontroller (BDC) in die Domäne eingebunden, zum PDC hochgestuft und danach auf Windows 2003 Server aktualisiert.

Weitere Domänencontroller können danach sauber von Grund auf neu installiert werden. Der aktualisierte Desktop-PC kann, nach Übertragung der Betriebsmaster-Rollen, wieder aus der Domäne entfernt werden. Der Hauptvorteil dieser Vorgehensweise ist die Erhaltung der Security Identifier (SID) der Benutzer und Gruppen. Es müssen keine aufwendigen Berechtigungsübernahmen durchgeführt werden.

Kritischer Pfad

Der kritische Pfad bei dem Update-Verfahren ist der sogenannte "native Mode", der für eine Migration nach Exchange 2003 Voraussetzung ist. Nur im "native Mode" können universelle Sicherheitsgruppen (USG) und die Gruppenschachtelung eingesetzt werden. USGs werden in den öffentlichen Ordnern für Berechtigungen verwendet, Gruppenschachtelung in aller Regel bei Verteilerlisten. Es müssen deswegen vor Beginn der Exchange-Migration alle NT4-Domänencontroller aus der Domäne herausgenommen werden. Leider wurden in der Vergangenheit oft wichtige Anwendungen auf Domänencontrollern installiert (beispielsweise SMS-, SNA- oder RAS-Server), deren Verlagerung auf Mitgliedserver nun ein Problem darstellt.

Beim Update des PDC auf Windows Server 2003 muss entschieden werden, in welchen Betriebsmodus die Domäne versetzt werden soll. Es kann zwischen zwei Modi gewählt werden:

• der gemischte Modus ("mixed mode"), in dem es NT4-, Windows-2000- und -2003-Domänencontroller geben kann;

• der "interim"-Modus, in dem nur NT4- und Windows-Server-2003-Domänencontroller erlaubt sind.

Dabei ist zu beachten, dass Windows Server 2003 neue Sicherheitsrichtlinien einführt. So wird beispielsweise die Signierung von SMB-Paketen grundsätzlich eingeschaltet. Ebenfalls wird das "secure channel signing" aktiviert. Beide Sicherheitsrichtlinien haben Einfluss auf NT4-Rechner, die Domänenmitglied sind. Erst ab NT4 mit Service Pack 4 können beide Richtlinien eingehalten werden.

Migration

Nachdem in der Designphase die neue Active-Directory-Struktur geplant wurde, erfolgen nun die klassischen Migrationsschritte:

• Neuinstallation der Domänenstruktur,

• Klonen der Benutzer- und Gruppenkonten.

Der Neuaufbau der Domänenstruktur bietet die einmalige Chance, einige Dinge von Grund auf sauber zu implementieren. Dazu gehören unter anderem:

• standardisierte Serverinstallationen;

• wohlüberlegtes Namensschema für Active-Directory-Objekte;

• am Bedarf orientierte administrative Delegation.

Cloning

Zum Klonen der Konten kann sowohl unter Windows 2000 Server als auch Windows Server 2003 das Active Directory Migration Tool Version 2 (ADMT) eingesetzt werden. Gegenüber ihrem Vorgänger bietet diese Version einige interessante Vorteile. Beispielsweise lassen sich nun Kennworte der Benutzer migrieren. Dazu muss auf einem der NT4-Domänencontroller die Passwortexportfunktion installiert werden. Ebenfalls neu ist die Script-Fähigkeit von ADMT. Bei länger dauernden Migrationsphasen können so mit Hilfe von ADMT-Scripts die Gruppenmitgliedschaften von alter und neuer Domäne synchron gehalten werden.

Berechtigungen

Eine weitere Hauptaufgabe während der Migration ist die Übernahme von Berechtigungsstrukturen der File-Server. Meist wird deswegen die ursprüngliche SID des NT4-Benutzers als "SID-History" in die neue Domäne übernommen. Dadurch können migrierte Benutzer weiterhin auf Ressourcen der alten Domäne zugreifen. Berechtigungsstrukturen können beispielsweise während der Kopie durch das Werkzeug robocopy.exe aus dem Windows Resource Kit mit dem Parameter /SEC übernommen werden. Allerdings werden die alten SIDs kopiert. Eine automatische Wandlung von alter zu neuer SID wird hier nicht durchgeführt.

Diese Tatsache ist von entscheidender Bedeutung, wenn das SID-History-Attribut der Benutzer- und Gruppenkonten nach der Migration gelöscht werden soll. Ohne SID-History besitzt der Benutzer keine Berechtigung mehr auf seine migrierten Daten. Deswegen muss hier ein reACLing stattfinden, das heisst, die alte SID muss durch die neue SID ersetzt werden. Zwei Werkzeuge bieten sich für diese Aufgabe an.

ADMT kann während der Migration von Computerkonten (beispielsweise der File-Server) SIDs austauschen oder zusätzlich hinzufügen. Da bei diesem Vorgang immer alle Partitionen des File-Servers bearbeitet werden, scheut man aber meist diese Vorgehensweise. Die bessere Lösung ist deswegen der SIDWalker Security Manager. Gesteuert durch eine Datei, in der Benutzer und Gruppenkonten von alter und neuer Domäne zugeordnet werden, können gezielt einzelne Verzeichnisse verarbeitet werden.

Zusätzliche Aufgaben

Zu einem Migrationsprojekt gehören meist noch weitere Aufgaben wie:

• Implementierung eines automatisierten Installationsverfahrens für Client und Server;

• Aufbau von Terminal-Servern, um ältere Hardware als Thin Client weiterverwenden zu können;

• Einrichtung von Print-Servern;

• Unix-Integrationen;

• Implementation einer Lösung zur Verteilung von Hotfixes und Service-Packs.

Zur Automatisierung von Client- und Serverinstallation werden oft die Microsoft Remote Installation Services (RIS) eingesetzt. RIS bietet die Möglichkeit, die Betriebssysteminstallation über ein Netzwerkboot (PXE, Preboot Execution Environment) zu starten. Unterstützt werden hier traditionelle unüberwachte Installationen wie auch Image-Installationen (riprepImage).

In Abhängigkeit vom Projektbudget kann es mitunter auch notwendig werden, die bestehende ältere PC-Hardware weiterverwenden zu müssen. In diesem Fall kann der Einsatz von Terminal-Servern kostengünstiger sein. Die alten Rechner lassen sich dann durch die Installation von NT4 oder Linux als Basisbetriebssystem plus RDP Client (für Windows Terminal Server) oder ICA Client (für Citrix Metaframe) in Thin Clients verwandeln. Durch den kostenlosen Einsatz von speziell angepassten Linux-Thin-Clients in Verbindung mit RIS können diese älteren PCs direkt vom RIS-Server gestartet wer-den und benötigen keine lokale Festplatte mehr.

Eine grosse Herausforderung ist dagegen der Aufbau von neuen Print-Servern. Hier muss erst entschieden werden, welche Treiberversionen auf diesen Print-Servern installiert werden sollen. Zwei Versionen werden hier unterschieden, die Version-2-Treiber (NT4) und die Version-3-Treiber (2000/2003/XP). Tools, die an dieser Stelle Verwendung finden können, sind:

• printmig.exe, um die Druckerkonfiguration eines bestehenden Print-Servers zu kopieren;

• fixprnsv.exe, um automatisiert Treiber nachzuinstallieren;

• VB-Scripts aus dem Windows 2000 Resource Kit (bei Server 2003 inklusive), mit denen das Anlegen von Ports und Druckern automatisiert werden kann.

Zu beachten bei Windows Server 2003 ist die Tatsache, dass Version-2-Druckertreiber standardmässig geblockt werden. Erst nach der Freischaltung durch eine Richtlinie können diese alten Druckertreiber installiert werden. In den meisten technisch orientierten Unternehmen besteht ausserdem die Anforderung, Unix-Clients und -Server in das Active Directory zu integrieren. Unix-Plattformen werden dort für CAD und andere technische Anwendungen verwendet. Durch Einsatz von Samba als SMB-Server auf Unix-Maschinen können Windows-Clients deren Datei- oder Druckerressourcen nutzen. Ein Samba-Server kann dabei als Mitgliedserver in einer Active-Directory-Umgebung arbeiten. Die oben genannten Sicherheitsrichtlinien (SMS, Signing und Secure Channel Signing) müssen je nach Samba-Version abgeschaltet werden.

Eine andere Variante der Integration bieten die Services for Unix (SFU) von Microsoft. SFU bietet die Funktionalitäten NIS-Server, NFS-Server oder -Gateway, User Name Mapping, Passwort-Synchronisation sowie das Interix Runtime System an. Ein Domänencontroller kann so als NIS-Masterserver agieren, der über das Active Directory die NIS-Maps passwd, group und hosts bereitstellt. Weitere NIS-Maps lassen sich über normale ASCII-Dateien bereitstellen. Diese Vorgehensweise bietet den Vorteil, dass sich Benutzer bei UNIX-Clients, die als NIS-Clients konfiguriert sind, mit ihrem Active-Directory-Benutzerkonto und -Passwort anmelden können. Über die Passwort-Synchronisation lassen sich schliesslich auch Passwortänderungen der Windows-Benutzer an NIS-Server weitergeben.

Microsoft bietet nun schon seit längerer Zeit die Software Update Services (SUS) an, mit denen Clients wie Server firmenintern mit Hotfixes versorgt werden können. Seit die Windows-Gemeinde durch den W32.Blaster.Worm kräftig durchgeschüttelt wurde, ist die Sensibilität hier sehr stark gestiegen. SUS bietet eine sehr einfach zu implementierende Lösung, mit der Hotfixes sehr schnell an viele Windows-Maschinen zu verteilen sind.

Kopplung von Active Directories

Durch den Zukauf von Firmenteilen wird es immer öfter notwendig, dass mehrere Active Directories oder globale Adresslisten integriert oder synchronisiert werden müssen. Bisher war dies nur durch den Einsatz der MMS (Microsoft Metadirectory Services) möglich. Zwischenzeitlich bietet Microsoft das Identity Integration Feature Pack for Microsoft Windows Server Active Directory an. Mit dessen Hilfe können Identitäten zwischen mehreren Active Directories oder den globalen Adresslisten von Exchange synchronisiert werden.

Windows 2000/2003/XP: Migration & Administration

Wolfgang Sauer, der Autor des Beitrags, ist Senior Consultant beim deutschen Systemhaus AddOn und einer der Referenten am Spezialevent "Windows 2000/2003/XP Migration & Daily Administration" der am 18. November durch die Usergroup NT-AG in Wallisellen bei Zürich in den Räumlichkeiten von Microsoft Schweiz durchgeführt wird. Das Forum bietet praxisorientierte Vorträge und Live-Demonstrationen für Profis für 448 Franken (inkl. Verpflegung und Trainingsvideos). InfoWeek-Abonnenten zahlen nur 348 Franken. Weitere Informationen finden Sie unter www.nt-ag.ch.