Active Directory erfährt auch in der künftigen Server-Version Windows Server “8” einige Erweiterungen. Diese sind zwar längst nicht so dramatisch wie jene in anderen Windows-Komponenten, doch allemal einen näheren Blick wert.
Alle Angaben beziehen sich auf die Developer Preview von Windows Server “8”, die derzeit den MSDN-Abonnenten zugänglich ist. Es handelt sich um eine Pre-Beta-Version, also kann sich noch alles ändern.
Im Wesentlichen konzentrieren die Neuerungen sich auf drei Bereiche:
- Virtualisierung und Cloning
- Management
- Neue Berechtigungsstrukturen für Dateiserver
Virtualisierung
Schon in den aktuellen Windows-Versionen ist es problemlos möglich (und auch unterstützt), Domänencontroller virtuell zu betreiben. Bislang gibt es dabei aber ein paar wesentliche Einschränkungen in den Virtualisierungsfunktionen, die man auf virtuelle Domänencontroller anwenden darf. So sollte man tunlichst davon absehen, DCs per VM-Snapshot zu konservieren und insbesondere auf einen Snapshot zurückzuspringen. Die Folge wäre ein USN-Rollback, durch das der “zurückgesetzte” DC nicht mehr korrekt an der AD-Replikation teilnimmt. Aus demselben Grund ist es derzeit nicht möglich, einen DC zu kopieren (klonen), um einen neuen DC daraus zu erzeugen: Auch hier würde ein USN-Rollback für gravierende Probleme sorgen.
In Windows Server “8” gibt es einen neuen Mechanismus, der beide Vorgänge für VM-DCs möglich macht. Man sollte sich allerdings der Grenzen bewusst sein, um nicht versehentlich doch in das USN-Problem zu laufen.
Die Snapshot-Unterstützung nutzt eine neue Funktion in Active Directory und in aktualisierten Virtualisierungs-Plattformen namens “VM-Gerenation ID”. In diesem Attribut hinterlegt der Hypervisor eine Kennung für die aktuelle Version der VM. Setzt man die VM auf einen früheren Snapshot zurück, so muss der Hypervisor diese ID ändern und über eine definierte Schnittstelle mitteilen.
Ein Domänencontroller unter Windows Server “8” speichert die VM-Generation ID in einem neuen AD-Attribut, das er lokal hält und nicht repliziert. Jeder virtuelle DC weiß so, auf welchem VM-Stand er sich befinden sollte. Vor jeder Änderung (Transaktion) in seiner Kopie der AD-Datenbank vergleicht der Domänencontroller nun seine gespeicherte ID mit derjenigen, die der Hypervisor an ihn berichtet. Stimmen sie überein, so geht der DC davon aus, dass er auf dem aktuellen Stand ist und führt die Transaktion aus. Sind die IDs hingegen unterschiedlich, so ist dies für den DC ein Signal, dass er auf einen älteren VM-Snapshot zurückgesetzt wurde. Er wird die Transaktion dann zurückstellen und zunächst eine Bereinigung ausführen. Hierzu erzeugt er eine neue Datenbank-Kennung (Invocation ID) und verwirft seinen RID-Pool (Relative Identifier), damit er keine Duplikate von Sicherheitsprinzipalen (Benutzer-, Gruppen- oder Computerkonten) erzeugt. Durch die neue Invocation ID erkennen alle anderen DCs einen neuen Replikationspartner und passen ihre Replikationsvorgänge auf diese Situation an. Im Wesentlichen entspricht der Vorgang demjenigen, der auch bei einem ordentlichen Recovery des Active Directory über ein Systemstate-Backup erfolgt. Erst nach Abschluss dieser Prozesse führt der DC die ausstehende Transaktion aus.
Wichtig dabei: Derzeit gibt es nur einen einzigen Hypervisor, der die neue Technik der VM-Generation ID beherrscht, und das ist Hyper-V 3.0 – also die neue Fassung von Windows Server “8”. Ältere Hyper-V-Versionen sowie alle anderen Anbieter können das (noch) nicht. Microsoft arbeitet aber nach eigener Aussage mit den anderen Herstellern zusammen, damit diese die Funktion ebenfalls implementieren. Ebenso wichtig: Auf Active-Directory-Seite unterstützt ebenfalls nur Windows Server “8” dieses Feature.
Dem Vernehmen nach rät Microsoft auch weiterhin davon ab, VM-Snapshots in Produktionsumgebungen für Domänencontroller zu nutzen. Stattdessen sind auch weiterhin die offiziellen Backup-Prozeduren zu verwenden. Die neue Funktion soll in erster Linie die fatalen Auswirkungen “versehentlicher” Snapshot-Rollbacks für DCs verringern.
Zudem ist zu berücksichtigen, dass die neuen Mechanismen ausschließlich mit virtuellen Domänencontrollern funktionieren. Image-Backups von DCs sind damit auch weiterhin keine nutzbare Alternative!
Die neue “VM-Generation ID” ist bislang nur sehr rudimentär öffentlich dokumentiert. Details zur Implementierung liegen noch weitgehend im Dunkeln. Dazu gehört auch die durchaus kritische Frage, wie ein virtueller DC vor Fehlern des Hypervisors geschützt wird. Denkbar ist etwa eine Situation, in der der Hypervisor keine neue ID erzeugt, obwohl er dies tun müsste. Auf der anderen Seite könnte es passieren, dass der Hypervisor durch eine Fehlfunktion oder einen Angriff ständig neue IDs erzeugt und damit einen DC handlungsunfähig macht, weil er laufend neue Invocation IDs erzeugen muss.
DC-Cloning
Der neue Mechanismus der VM-Generation ID bildet auch die Grundlage für das erstmals unterstützte Klonen von Domänencontrollern. Dadurch kann man neue DCs auf Basis einer Vorlage erzeugen und so deutlich schneller ausrollen als bisher. Man sollte dabei allerdings in Betracht ziehen, dass auch der traditionelle Weg, einen neuen DC zu erzeugen, in den meisten Umgebungen weniger als eine halbe Stunde Zeit erfordert. Das Cloning sollte daher nicht als neuer Königsweg gelten, sondern eher als zusätzliche Option.
Das Klonen von DCs erfordert in Windows Server “8” einige Vorbereitungen. Zunächst braucht es mindestens zwei DCs mit dem neuen Betriebssystem: Den PDC-Emulator (Inhaber der entsprechenden Betriebsmasterrolle) und einen weiteren DC, der als Vorlage für die Klone dient. Der PDC-Emulator selbst kann nicht als Vorlage herhalten – in neu aufgesetzten Domänen ist dies stets der allererste DC.
Um die Klon-Funktion zu nutzen, muss man zunächst den Vorlagen-DC als solchen autorisieren. Dies geschieht über eine neue AD-interne Berechtigung auf Domänenebene, die man dem DC-Computerkonto zuweist (“Allow a DC to create a clone of itself”). Durch diesen Vorgang soll die Berechtigung, DC-Klone zu erzeugen, in der Hoheit der AD-Administratoren liegen, damit die Betreiber der VM-Umgebung nicht wahllos Kopien dieser sensiblen Komponente erzeugen.
In einem zweiten Schritt muss man dann eine Reihe von XML-Dokumenten erzeugen, die den Namen und die Netzwerkkonfiguration des neuen Klon-DCs sowie Informationen zu weiteren lokal laufenden Applikationen und Komponenten enthalten. In der aktuellen Preview-Version des Server-Windows gibt es keine grafischen Editoren dafür, man muss sie also im Quelltext bearbeiten.
Für das eigentliche Cloning fährt man den Vorlagen-DC herunter und kopiert dann die virtuelle Festplatte oder über die VM-Verwaltung die ganze VM. Der Hypervisor muss dabei eine neue “VM-Generation ID” erzeugen – was (siehe oben) derzeit nur Hyper-V 3.0 beherrscht. Beim ersten Start des Klon-DCs stellt dieser dann anhand der ID und der XML-Dateien fest, dass er geklont wurde, und kontaktiert den PDC-Emulator, um sich ins AD einzubinden. Falls im Konfigurations-XML kein Name und keine Netzwerkkonfiguration vorgegeben ist, generiert der PDC-Emulator eine neue Identität und weist sie dem neuen Klon zu. Diese letztere Funktion unterstützt vor allem Massen-Rollouts und die Automatisierung in großen Cloud-Umgebungen.
Microsoft positioniert die neue Funktion vor allem für große Umgebungen mit hohen Automatisierungs-Anforderungen sowie zur Vereinfachung des Forest Recovery in großen Netzwerken. Wie oben angemerkt, dürfte sie für kleine und mittlere Netzwerke kaum eine sinnvolle Erleichterung darstellen.
Management
Für die Verwaltung von Active Directory hat Microsoft besonders das “Active Directory Administrative Center” mit dem schönen Kürzel “ADAC” erweitert, das erstmals mit Windows Server 2008 R2 vorgestellt wurde. Im Gegensatz zur aktuellen Fassung wird die neue Version deutlich erweitert sein und nicht nur einfache Basis-Operationen unterstützen.
Neben der besseren Verwaltung von AD-Berechtigungen bringt das neue ADAC vor allem eine grafische Oberfläche für den AD-Papierkorb (AD Recycle Bin) mit, der zwar mit Windows Server 2008 R2 schon zur Verfügung steht, aber dort noch ohne eigene Oberfläche daherkommt. Das Wiederherstellen versehentlich gelöschter Objekte ist so viel einfacher möglich.
Auch für die “Fine-Grained Password Policies” gibt es nun eine grafische Oberfläche im ADAC. Diese Funktion gibt es bereits seit Windows Server 2008, doch ist sie weitgehend unbekannt geblieben, weil eben kein GUI dafür bereitsteht. Durch diese Policies ist es möglich, mehr als eine Kennwortrichtlinie in derselben Domäne umzusetzen und etwa administrative Konten besser zu schützen als die “Allgemeinheit”.
Schon in der 2008-R2-Fassung beruht das ADAC auf der PowerShell. In der neuen Version bringt es nun eine “PowerShell History” mit, sodass man GUI-Vorgänge besser in PowerShell-Skripts übernehmen kann. Vielleicht führt dies durch Einübung zu einer weiteren Verbreitung der PowerShell in Admin-Kreisen.
Außerhalb des ADAC wurde vor allem die Installation von Domänencontrollern überarbeitet. Erstmals seit Windows 2000 gibt es nun kein “dcpromo” mehr. Das vormals separate Kommando zum Hoch- oder Runterstufen eines DCs ist nun vollständig in den neuen Server-Manager sowie in die PowerShell überführt worden. Der neue Installationsprozess automatisiert nun weit mehr Vorgänge als bisher, was vor allem beim nachträglichen Einfügen neuer DCs in bestehende Domänen hilfreich ist. Das früher ebenfalls separate “adprep.exe” ist nun nicht mehr notwendig, aber als Option weiter verfügbar (in der Developer Preview allerdings nur als x64-Version für Windows Server 2008 und R2!).
Die PowerShell-Commandlets für Active Directory sind künftig deutlich umfangreicher als zuvor. Vor allem bringen sie nun alles mit, was man zum Steuern und Überprüfen der AD-Replikation benötigt. Das lässt sich durchaus als Hinweis verstehen, dass die bisherigen Kommandozeilentools für diese Vorgänge bald evtl. nicht mehr unterstützt werden.
Neue Berechtigungsstrukturen für Dateiserver
Eher in die Kategorie “Revolution” fällt ein neues Berechtigungssystem für Dateiserver. Unter dem Namen “Flexible Access” wird Windows Server “8” erstmals ein neues Prinzip der Zugangsverwaltung mitbringen, das nicht mehr ausschließlich auf festen Berechtigungslisten (Access Control Lists, ACL) beruht. Mit Hilfe dieser Technik wird es möglich sein, den Zugriff auf Dateien über verschiedene Attribute zu steuern. Neben der Mitgliedschaft in Gruppen können dazu weitere Eigenschaften eines Users zählen, etwa der eingetragene Standort. Solche Daten kann ein “8”-Dateiserver mit Tags vergleichen, die Dateien oder Ordnern zugewiesen sind. So lassen sich Logiken aufbauen wie “Zugriff erhalten Anwender aus der Zentrale, die in der Personalabteilung arbeiten”.
Diese Funktion wird einiges an näherer Betrachtung erfordern, und es handelt sich nicht ausschließlich um ein Active-Directory-Feature. In zukünftigen Artikeln werden wir uns damit beschäftigen.
http://faq-o-matic.net/?p=3630