Virtuelle Domänencontroller clonen

Schnelles Reagieren im Falle eines Domänencontroller-Blackouts und das sofortige Bereitstellen von mehr Domänencontroller-Ressourcen – diese Vorteile lassen sich durch das Clonen von virtuellen Domänencontrollern (DCs) realisierten.

Ab Windows Server 2012 wird diese Aktion in einer AD-Gesamtstruktur unterstützt. Unser Experte Sean Deuby zeigt, was ein Administrator dabei noch zu beachten hat und wie der rote Faden für das Clonen von virtuellen Domänencontrollern aussieht.

Eine spezielle Charakteristik macht die Virtualisierung so interessant: da eine virtuelle Maschine (VM) komplett in Form von Software existiert und keine physischen Komponenten aufweist, sollte man sie binnen kürzester Zeit kopieren – sprich clonen – können. Dabei sollte man sich auch keine Probleme einhandeln – wie etwa eine Reduzierung der Systemintegrität.

Das Clonen einer VM ist daher auch zu einem beliebten Vorgehen geworden, um zusätzliche logische Ressourcen bereit zu stellen. Doch dabei stellt sich noch die Frage: lassen sich auch VMs clonen, die eine beliebige Applikation ausführen? Die Antwort darauf lautet – wie so häufig: Es kommt darauf an…

Diese eher weiche Formulierung macht aber durchaus Sinn, wenn man sich die Inhalte einer VM in den verschiedenen Ebenen ansieht und dabei bestimmt, was in der jeweiligen Ebene einzigartig ist.

Clonen verboten – so lautete die Devise für das Active Directory

Einige Bestandteile einer VM, wie etwa die virtuelle Festplatte und die Konfigurationsinfos der VM, lassen sich immer clonen. Doch wie sieht das mit dem Gastbetriebssystem in der VM aus? Auch hier wird man zunächst ein Ja zum Clonen sagen, doch wenn eine enge und eindeutige Kopplung mit den physischen Komponenten besteht – wie das zum Beispiel bei einer Pass-Through-Disk der Fall ist – dann wird die Sache schon komplexer.

Andere Bereiche, in denen eine „Einzigartigkeit“ auftritt, sind der Systemname und seine IP-Adresse, wenn diese Ressourcen zugewiesen sind.

Ist eine VM mit einer Domäne verbunden, dann entsteht ein weiterer Konflikt: Der SID (Security Identifier) der Kopie entspricht dem des Originals – und das darf in einer Domäne nicht der Fall sein. Ein SID muss innerhalb einer Domäne einzigartig sein. Um das Problem mit der SID zu lösen, gibt es einige Tools – wie etwa die Sysprep-Utility von Microsoft. Damit muss für das geclonte System (also die neue VM) ein neuer SID erzeugt werden.

Des Weiteren gibt es auch Abhängigkeiten auf der Anwendungsebene. Im AD DS (Active Directory Domain Service) gab es bisher eine klare Einschränkung für das Clonen von Domänencontrollern: Ein jeder DC ist ein integraler Bestandteil eines kompletten DC-Verbundes, der aus verteilten Systemen besteht. Auch wenn man einen DC schnell austauschen möchte, wenn er ausfällt, so muss der Administrator doch darauf achten, dass das komplette verteilte System informiert wird, dass dieser Austausch stattfindet.

In den meisten Fällen teilt ein DC, dessen Zustand sich verändert hat, es den anderen DCs mit – das erfolgt im Zuge der Replikation der DCs untereinander. Ein typisches Beispiel dafür ist das Benachrichtigen der Replikationspartner, wenn der DC aus einem validen Backup wiederhergestellt worden ist.

Das fast schon grenzenlose Vertrauen auf diese Selbstüberprüfung hat aber auch Nachteile. Daher wurden im Verlauf der AD-Entwicklung einige Schutzmechanismen eingeführt: Falls ein DC ein bestimmtes Verhalten bemerkt – wie etwa den Versuch, Attribute für ein Objekt zu replizieren, das bereits gelöscht wurde – dann hält er alle weiteren Aktualisierungsaktionen mit seinem Replikationspartner an.

Wer mit einem DC auf der Basis von Windows Server 2008 Release 2 (oder frühere Versionen) Virtualisierungsaktionen (wie das Clonen) ausgeführt hat, der sah sich oftmals mit sehr bösen Situationen konfrontiert. Diese sind auch beim Support im Hause Microsoft recht häufig gemeldet worden, daher kann man davon ausgehen, dass diese Aktionen sehr häufig ausgeführt wurden – frei nach dem Motto: Wenn es das System zulässt, muss es auch erlaubt und sicher sein.

Änderung ab Windows Server 2012

Daher hat sich das Entwicklerteam bei Microsoft dazu entschlossen, mit dem Windows Server 2012 auch das Virtualisieren des AD auf eine sichere Art und Weise zu unterstützen. Sie haben dazu die VM Gen ID (VM-GenerationID) eingeführt. Dabei handelt es sich um eine zusätzliche Logik, die in das betreffende Betriebssystem und das AD eingebaut wurde. Mehr Details dazu zeigt der Beitrag „Weiterentwicklung des AD beim Windows Server 2012“.

Clonen bringt mehr Flexibilität ins Spiel

Da mit Windows Server 2012 das AD „virtualisierungssicher“ gemacht wurde, ergibt sich sozusagen als Seiteneffekt auch, dass ein Clonen im AD-Umfeld (also von Domänencontrollern) stattfinden darf. Damit lässt sich ein großer Vorteil nutzen: Der Administrator ist damit in der Lage, sehr schnell zusätzliche Ressourcen für das AD bereitzustellen.

Vor Windows Server 2012 war der Weg zu einem zusätzlichen DC in einer AD-Gesamtstruktur noch sehr steinig: Man musste – bei einem virtuellen DC – erst eine neue VM anlegen und danach mithilfe von Dcpromo diese VM mit dem darin installierten Server-Gastbetriebssystem zu einem DC hochstufen. Das ist in kleineren AD-Umgebungen kein allzu zeitraubender Vorgang, doch wer ein großes AD betreiben muss und dadurch eine sehr große AD-Datenbank (ntds.dit) vorliegen hat, der wird doch sehr lange dafür brauchen.

Wer in der Lage ist, sehr schnell neue DCs in die Gesamtstruktur einzubringen, der kann auch im Falle eines Systemabsturzes an einem oder mehreren DCs recht zügig einen Desaster Recovery-Vorgang für seine AD-Gesamtstruktur oder AD-Domäne durchführen.

Hat ein Unternehmen eine eigene „Private Cloud“ im Einsatz, dann versetzt ihn das Clonen von DCs in die Lage, die Infrastruktur für das Authentifizieren und das Autorisieren in der Private Cloud genauso elastisch anzulegen wie den Rest seiner IT-Umgebung. Wer schnell eine Testumgebung aufbauen muss oder in einer Zweigstelle schnell zusätzliche Kapazität für das AD spendieren muss, dem wird das Clonen von DCs in die Karten spielen.

Sicherheitsvorgaben müssen passen

Doch wie für jedes Feature, das Auswirkungen auf die bestehende Sicherheits-Infrastruktur aufweist, sind entsprechende administrative und sicherheitsbezogene Vorgaben einzuhalten. Konkret gesprochen darf nicht ein jeder einen neuen DC anlegen. Die administrative Herausforderung einer jeden in Schichten aufgebauten Infrastruktur besteht darin, dass jeder, der die unteren Ebenen kontrolliert, auch die oberen Ebenen beeinflussen kann. Zum Beispiel könnte selbst der weltweit schnellste SQL Server Cluster nicht viel ausrichten, wenn er über keinen Netzwerkanschluss verfügt.

In einer virtualisierten AD-Infrastruktur haben die Hypervisor-Administratoren die vollständige Kontrolle über alle VMs und daher auch über alle virtuellen Domänencontroller (VDCs). Generell ist es nicht möglich, Einschränkungen zu definieren, die vorgeben, welchen DC der Hypervisor Administrator clonen darf. Daher musste das AD-Team bei Microsoft einige Sicherheitsfunktionen in den Cloning-Prozess einbauen. Damit wird nun sichergestellt, dass diese Aktion ausgeführt werden darf, wenn ein virtueller Domänencontroller auch als vertrauenswürdiges Quellsystem für das Clonen freigegeben wurde.

Der Ablauf des Cloning-Vorgangs

Ehe der Administrator einen virtuellen Domänencontroller auf der Betriebssystemplattform Windows Server 2012 clonen kann, müssen sowohl der physische Server (und die Virtualisierungsplattform – also der Hypervisor), auf dem der Quell-VDC läuft, als auch der physische Server (plus Hypervisor), auf dem die Ziel-VDC zum Einsatz kommen soll, die „VM Gen ID“ unterstützen.

Derzeit unterstützt beim Microsoft lediglich der Hyper-V (auf der Basis von Windows Server 2012) diese Technik, bei VMwares Virtualisierungsplattform vSphere 5.0 war es noch nicht enthalten (die Version 5.1 soll es allerdings können). Auch Citrix will sich der VM Gen ID annehmen.

Der DC mit der Rolle des PDC Emulators (Primary Domain Controller) für die Domäne muss ebenfalls auf der Basis von Windows Server 2012 arbeiten (doch man kann ihn nicht clonen). Dann kann man alle anderen DC, die auf Windows Server 2012 aufsetzen, clonen – frühere Windows-Serverbetriebssysteme dagegen nicht. Wenn man bereits DCs mit Windows Server 2012 in seiner Umgebung einsetzt, bedeutet das in der Regel auch, dass man die Gesamtstruktur und die Domänen auf den Windows Server 2012 aktualisiert hat.

Sind diese Voraussetzungen alle erfüllt, sind die folgenden Schritte abzuarbeiten, um einen DC zu clonen:

Zuerst muss ein virtueller DC die Berechtigung bekommen, dass er gecloned werden darf. Dazu muss er der Sicherheitsgruppe „Cloneable Domain Controllers“ hinzugefügt werden. Das lässt sich mithilfe eines üblichen AD-Verwaltungswerkzeug erledigen, wie etwa dem ADAC (Active Directory Administrative Center) oder dem ADUC (Active Directory Users and Computers). Zudem bietet die Powershell für diese Aufgabe das Cmdlet Add-ADGroupMember.

Als nächstes sollte man bestimmen, ob Programme oder Dienste auf dem Quell-VDC laufen, die sich nicht sicher clonen lassen. Dies Aufgabe erledigt erneut ein Powershell-Cmdlet: Get-ADDCCloningExcludedApplicationList.

Diese Liste sollte der Administrator genau untersuchen und dann noch die Programme oder Dienste dazu nehmen, von denen er glaubt, dass sie sich sicher clonen lassen. Diese Informationen kann der Hersteller der Applikation liefern, oder aber man muss in den sauren Apfel beißen und eigene Tests ausführen.

Die Ergebnisse sind dann in die Datei CustomDCCloneAllowList.xml einzutragen. Dieser Aufwand wird recht gering sein, wenn man bei seinen DCs eine Regel berücksichtigt hat: Auf einem DC soll immer nur die minimal nötige Menge an Anwendungen und Diensten laufen.

Nach diesen Vorarbeiten muss der Administrator auf dem Quell-VDC das Cmdlet New-ADDCCloneConfigFile laufen lassen. Bei diesem Cmdlet kann man dann auch neue Parameter für den geclonten VDC angeben, wie etwa den Systemnamen, die IP-dresse, die Subnetzmaske, die DNS-Server und die Bezeichnung des AD-Standorts, an dem der geclonte VDC eingesetzt werden soll.

Danach  muss man den Quell-VDC herunterfahren und dann exportieren.
Anschließend ist die erzeugte Kopie (also der Clone) auf dem Ziel-Host zu importieren und dann zu starten.

Eine sehr detaillierte Anleitung für den gesamten Cloning-Vorgang und die Voraussetzungen gibt der Microsoft-Beitrag „Active Directory Domain Services (AD DS) Virtualization“.

Da auf dem Quell-VDC das Cmdlet New-ADDCCloneConfigFile zum Einsatz kommen muss, man dann den VDC herunterfahren und dann den Clone exportieren muss, erweist sich dieser Vorgang in einer Produktivumgebung mitunter als eine Herausforderung.

In größeren AD-Verbunden, bei denen zudem die Cloning-Vorgänge häufiger ausgeführt werden, werden daher die Quell-VDC in einem eigenen Standort ohne Benutzer-Subnetze platzieren. In einer derartigen Konstellation führt das Herunterfahren des VDC zu keinen negativen Auswirkungen auf die Produktivumgebung.

Sean Deuby/rhh