Hyper-V und Domänencontroller auf einem System betreiben?

9. April 2014

Bild 1. Beim Einsatz von Hyper-V sollte auf eine gleichzeitige Hochstufung zum Domänencontroller verzichtet werden.

In den Best Practices gibt Microsoft vor, die Rolle des Hyper-V nicht zusammen mit dem Active Directory auf einer physikalischen Maschine zu betreiben – ein Hyper-V-System soll also nicht gleichzeitig auch ein Domänencontroller (DC) sein. Allerdings stellen sich viele Administratoren im Umfeld kleiner und mittlerer Betriebe die Frage, warum das so nicht praktiziert werden sollte. Denn schließlich lassen sich so Hardwarekosten sparen, denn für beide Dienste könnte ja ein einziges System verwendet werden. Auch eventuell auftretende Probleme mit der Virtualisierung des Domänencontrollers könnten so gut umgangen werden. Zudem ließen sich ja noch Lizenzkosten sparen, schließlich muss der Systembetreuer bei dieser Konfiguration nur eine einzige Maschine lizensieren. Diese Pluspunkte für eine Nutzung von Hyper-V und DC auf einem nativen Server werden bei genauem Hinsehen allerdings zu Negativargumenten. Dies wird das NT4ADMINS-Team im folgenden Beitrag aufzeigen.

Im Zuge der breiten Akzeptanz von Virtualisierungs-Technologien und der dadurch möglichen optimalen Ausnutzung von vorhandenen Systemressourcen können Systembetreuer verleitet werden, diese parallelen Einsatzszenarios auch auf physikalische Maschinen zu übertragen. So liegt der Gedanke nahe, einen Hyper-V-Server auch gleichzeitig als Domänencontroller einzusetzen.

Doch viele Systembetreuer scheuen sich, einen DC als virtuelle Maschine innerhalb einer Hyper-V-Umgebung einzusetzen. Das ist zwar ein durchaus sinnvolles Einsatzszenario, allerdings sprechen verschiedene Gründe gegen einen virtuellen DC. Beispielsweise könnte es bei Fehlern zu folgender paradoxen Situation kommen: Die VMs (und damit auch der virtuelle DC) können nicht starten weil das Active Directory nicht läuft, und umgekehrt kann das Active Directory nicht zum Laufen gebracht werden, weil der DC in der virtuellen Maschine nicht startet.

Oftmals wird sich in größeren Unternehmen damit beholfen wenigstens einen DC auf Basis einer physikalischen Maschine quasi als Notfall-Backup bereitzuhalten. Dass macht auch im Umfeld kleinerer Unternehmen Sinn, nur sollte dafür eine dedizierter Server herangezogen werden. Die parallele Nutzung eines Servers für sowohl Hyper-V als auch der Domänencontroller-Rolle ist aus unterschiedlichen Gründen nicht sinnvoll und sollte daher vermieden werden.

Absicherung der Domänenstruktur

Eines der Grundkonzepte von Virtualisierungs-Lösungen ist die strikte Trennung der einzelnen VMs. In diesem Zusammenhang gilt es auch, den Hypervisor entsprechend abzuschotten. Trotzdem sind Szenarien denkbar, in denen potentielle Angreifer etwa durch Sicherheitslücken aus dem VMs „ausbrechen“ und somit den Hard- oder Software-Zugriff auf die Hostplattform erlangen können. Dies ist nicht nur ein theoretischer Gedankengang, sondern es wurde bereits Mitte 2012 eine solche Sicherheitslücke bei Intel CPUs bekannt.

Falls sich nun ein Angreifer Zugriff auf das Hypervisor-System verschafft, und dieser Server zusätzlich mit einer Domänencontroller-Rolle versehen ist, tritt ein noch weitaus größeres Problem auf: Nicht nur der Hyper-V-Server und die darauf laufenden virtuellen Systeme sind dann kompromittiert, sondern das gesamte Active Directory. Der Angreifer könnte so die volle Kontrolle über das Unternehmensnetzwerk erlangen und einzelne Benutzerkonten oder Gruppen anlegen oder sie sperren beziehungsweise auch sämtliche Datenbestände manipulieren oder auslesen.

Sicherheitsbewusste Administratoren sehen wegen dieses Arguments vom Einsatz virtueller Domänencontroller ab und wägen einen Einsatz der DCs innerhalb virtueller Umgebungen sorgfältig ab. Beispielsweise würde auch eine Trennung der virtuellen Server- und Clientsystemen die Sicherheit deutlich erhöhen, denn damit würden keine sicherheitskritischen VMs auf demselben Hypervisor-System laufen wie etwa Produktivserver und virtuelle Domänencontroller.

Performance Probleme

Bei der Hochstufung eines Servers zum Domänencontroller werden standardmäßig die Schreib-Caches der jeweiligen Datenträger deaktiviert. Microsoft gibt dies aus Sicherheitsgründen vor, schließlich könnten Inkonsistenzen der Schreibzugriffe, wie sie etwa bei Systemabstürzen mit aktiviertem Cache vorkommen können, das Active Directory beschädigen. Zwar lässt sich dieses Verhalten auch mit einem Microsoft-Hotfix beheben, allerdings geschieht dies — so Microsoft – auf eigene Gefahr.

Bei Domänencontrollern verlangsamt das Deaktivieren des Schreib-Caches das System nicht zu stark. Ganz anders sieht die Sache beim Einsatz auf Hyper-V-Hostsystemen aus. Denn hier wird nicht nur der Hypervisor beeinträchtigt, sondern naturgemäß auch alle VMs, die sich auf dem Hostsystem befinden. Dadurch resultieren im denkbar schlimmsten Fall sogar extreme Performance-Einbußen, daher ist der Einsatz von Hyper-V und Domänendiensten auf einem physikalischen System auch aus der Sicht der Systemperformance nicht ratsam.

Microsoft bietet keinen Support bei Problemen

Nachdem Microsoft die parallele Nutzung von Hyper-V und Domänencontroller-Rollen auf einem System nicht unterstützt, kommt noch eine weitere Schwierigkeit hinzu. Microsoft wird bei Fehlern oder Problemen mit dieser Konstellation keinerlei Support bieten. Hier könnte man entgegen, dass der zuständige Systembetreuer bisher auch noch nicht auf Microsoft-Supportanfragen angewiesen war.

Allerdings gilt es zu bedenken, dass die „echten Experten“ bei kniffligen Fehlern entweder aus der Riege der Microsoft-Mitarbeiter kommen, oder zumindest sehr eng mit diesen zusammenarbeiten. Diese erweitern ihr Expertenwissen unter anderem durch Anfragen in den entsprechenden Microsoft-Foren oder eben auch mittels eigener Supportanfragen. Daher wird es bei kniffligen Fragen schwierig an fundiertes Expertenwissen zu kommen, falls nicht unterstützte Konfigurationen für Probleme sorgen.

Härtung des Hyper-V-Systems über Gruppenrichtlinien wird erschwert

Durch die Installation der DC-Rolle wird das entsprechende System auch auf der Sicherheitsebene umgekrempelt. Beispielsweise befindet sich auf einem Domänencontroller keine lokaler „Security Account Manager“ (SAM) oder eine vergleichbare Funktion. Daher ist hier nur die Anmeldung mittels eines AD-Accounts möglich. Das kann bei Fehler in der Domäne (respektive im AD) die letzten Rettungsanker kappen. Schließlich wäre es ansonsten noch möglich, sich am Hyper-V-System lokal anzumelden und Wartungen, Reparaturen oder Wiederherstellungen vorzunehmen. Falls sich allerdings kein SAM mehr auf dem System befindet, ist eine lokale Anmeldung unmöglich.
Ein weiterer Punkt ist das Vorgehen des Hyper-V-Managers bei der Installation. Hier wird normalerweise ein lokaler Account mit der Bezeichnung „Hyper-V Administratoren“ angelegt, um die ordnungsgemäße Funktion des Hypervisors sicherzustellen. Das ist so in einem DC aufgrund des fehlenden SAMs nicht möglich, daher wird der „Hyper-V Administratoren“-Account eventuell nicht wie vorgesehen implementiert. Hier kann es vorkommen dass Hyper-V zwar zunächst einwandfrei funktioniert, aber später plötzlich gravierende Fehler auftauchen.

Die Härtung des Hyper-V-Systems mittels Gruppenrichtlinien ist ein sinnvoller Ansatz um die Sicherheit signifikant zu erhöhen. Dies ist allerdings problematisch, falls sich DC und Hyper-V-Host in derselben Organisations Einheit (OU) befinden. Das geschieht allerdings falls der Systembetreuer Hyper-V und DC auf demselben physikalischen Unterbau zusammenfasst. Die Härtung von Hyper-V-Systemen mittels Gruppenrichtlinien wurde bereits in einer Beitragsserie von NT4ADMINS ausführlich behandelt. Im ersten Teil dieser Serie wird unter anderem die Härtung mittels Gruppenrichtlinien genauer unter die Lupe genommen

Ohne Live Migration wird die Flexibilität begrenzt

Falls der betreffende Server aufgrund des Alters oder Hardwareproblemen ausgetauscht werden soll, kommt in der Regel eine „Shared Nothing Live Migration“ zum Einsatz. Somit wird das betreffende virtuelle System im laufenden Betrieb auf den bereits vorbereiteten aktuellen Host transferiert. Sollte der sich der DC allerdings zusammen mit dem Hyper-V-Host auf demselben physikalischen Unterbau befinden, ist eine Live Migration naturgemäß nicht möglich. Schließlich steht diese Funktion nur bei VMs zur Verfügung. Daher wird der Systembetreuer hier einiges an Zeit für einen Transfer des Active Directorys aufwenden.

Fazit

Ob nun aus Sicht der Systemgeschwindigkeit, der Fehlerbehebung oder der Sicherheitsaspekte betrachtet: Hyper-V und Domänencontroller-Dienste gehören nicht auf dasselbe physikalische System. Auch die zunächst bejahenden Argumente wie etwa die Lizenzierung, Einsparung der Hardwarekosten oder die vermeintliche Problemlösung beim Einsatz von virtuellen DCs lassen sich wiederlegen. So entstehen etwa keine Lizenzierungsvorteile, beim Einsatz einer Hyper-V- und DC-Doppelkonfiguration auf ein und derselben Maschine. Diese muss nämlich ebenfalls voll lizenziert werden, ebenso wie sich der Sachverhalt beim Einsatz von Hyper-V und virtuellen DC gestaltet.

Das Problem mit virtuellen DCs kann auch durch eine parallele Nutzung des Hyper-V-Servers nicht korrekt umgangen werden. Denn bei Fehlern im AD ist meist auch eine Anmeldung am DC problematisch, da sich keine lokalen Accounts mehr auf dem hochgestuften Hyper-V-Server befinden ist eventuell auch keine Anmeldung am Hypervisor möglich.

Einzig die Einsparung zusätzlicher Hardwarekosten bleibt noch anzumerken, aber im Hinblick auf die fehlende Unterstützung seitens Microsoft relativiert bei Systemproblemen und etwaigen Fehlern diese Ansicht zuungunsten einer solchen kombinierten Lösung. Die restlichen Punkte wie etwa mangelhafte Sicherheit und die garantierten Performanceeinbußen sollte schlussendlich auch die letzten Zweifler überzeugen. Hier lohnt sich sowohl für kleine als auch mittlere Unternehmen die Investition in einen dedizierten Server, der als physikalischer Domänencontroller im Unternehmensnetzwerk seinen Dienst verrichtet. Umsichtige Administratoren setzten zusätzlich noch weitere virtuelle DCs auf, und erhöhen so in den Netzwerken die Ausfallsicherheit.