Hyper-V, Domain Controller und die Zeit

Server Virtualisierung ist hoch im Kurs und auch Domain Controller werden inzwischen fleissig virtualisiert. Wer allerdings einen Domain Controller als Virtual Machine betreibt, sollte besonderes Augenmerk auf die korrekte Zeitsynchronisation legen. Grundsätzlich sollte dies kein Problem darstellen, denn…

… jeder Active Directory Client synchronisiert seine Zeit mit einem Domain Controller
… jeder Domain Controller gleicht seine Zeit mit dem PDC Emulator (Primary Domain Controller Emulator) FSMO Rolle ab.
… der Domain Controller mit der PDC Emulator FSMO Rolle kann die Zeit mit einer externen Zeitquelle abgleichen.

Was wenn die Zeit “falsch” ist? Doch “falsch” ist nicht gleich “falsch” – Haben alle Active Directory Clients die gleiche falsche Uhrzeit konfiguriert, so funktioniert die Authentifizierung nach wie vor. Doch wird nur bei einzelnen Computer oder Domain Controller eine falsche Uhrzeit konfiguriert, kann dies zu grossen Problemen führen. Denn bereits eine Abweichung von fünf (5) Minuten reicht aus, damit die Kerberos-Tickets ihre Gültigkeit verlieren.

Dead on arrival?

Seit Windows Server 2008 wird kein Microsoft Zeitserver (time.windows.com) mehr vorkonfiguriert. Dies bedeutet dass auch kein automatischer Abgleich mehr erfolgt. Auf diesen Umstand wird nun im Active Directory Best Practices Analyzer von Windows Server 2008 R2 entsprechend hingewiesen:

The PDC emulator master srv-dc01.intra.server-talk.eu in this forest should be configured to correctly synchronize time from a valid time source

Diesen Fehler gilt es nun zunächst zu korrigieren, doch auch funktioniert das cmdlet net time nicht mehr wie früher. Eine Möglichkeit für Windows Server 2008 R2 wäre folgender Befehl. Dieser kann in einem Command Prompt als Administrator ausgeführt werden: w32tm /config /computer:srv-dc01.intra.server-talk.eu /manualpeerlist:ntp.metas.ch /syncfromflags:manual /update

In diesem Beispiel wird der NTP Server von METAS verwendet. METAS  ist das nationale Metrologieinstitut der Schweizerischen Eidgenossenschaft. Der Abgleich mit dem Zeitserver im Internet erfolgt jeweils mittels UDP 123. Dieser Port muss auch entsprechend auf der Firewall geöffnet werden, damit der Domain Controller mit dem Internet kommunizieren kann.

Do’s and Dont’s – was man vermeiden sollte

In einer Infrastruktur wo Domain Controller virtuell betrieben werden gilt es zudem noch weitere Punkte zu beachten:

Auch ein Hypervisor aktualisiert die Zeit seiner Guests. Um Probleme zwischen Hyper-V Host und Virtual Machines zu verhindern, muss bei den Domain Controller in den Integration Components, VMware oder Xen Tools die Zeit Synchronisation deaktiviert werden.

Eine Virtual Machine muss immer heruntergefahren (Shutdown) und darf nie pausiert werden. Da bei einer Pause Zeit / Datum nicht verändert werden, kann unter Umstände nicht mehr repliziert werden und es können veraltete Objekte (Lingering Objects) entstehen.

Für einen Domain Controller sind Snapshots und Undo Virtual Hard Disks (VHDs) sind absolut tabu! Eine falsche Anwendung kann in einem Desaster mit Verlust von Active Directory Informationen enden.

Pro Domain muss mindestens ein physikalischer Domain Controller inklusive GC, DNS und den FSMO Rollen existieren. Wenn dennoch sämtliche Domain Controller virtualisiert wurden, sollten diese zumindest nicht auf ein CSV Volume gespeichert werden, um ein einfacheres und schnelleres Recovery durchführen zu können.

Dazu hat Microsoft ein umfangreiches Dokument veröffentlicht. Der Reference Guide kann jeweils direkt im Microsoft Download Center heruntergeladen werden: Running Domain Controllers in Hyper-V. Zum Lesen von Word Dokumenten ist Microsoft Office Word oder der Microsoft Word Viewer erforderlich.

Windows Patch-Level

Bevor eine Virtual Machine als Domain Controller in Betrieb genommen wird, muss noch sichergestellt werden dass diese im Minimum folgenden Patch-Level aufweisen:

OPERATING SYSTEM	SERVICE PACK	HOTFIXES
Windows 2000 Server	Service Pack 4	KB885875
Windows Server 2003	Service Pack 2	KB875495
Windows Server 2008	Service Pack 1 (RTM)	-

Weitere Informationen

• Microsoft KB 888794: Things to consider when you host Active Directory domain controllers in virtual hosting environments
• Jorge’s Blog: Lingering objects
• Yusuf’s Blog: Lingering Objects (veraltete Objekte)

Die FSMO-Rollen mit DCPROMO verschieben

Wenn ein Domänencontroller (DC) ausgetauscht wird, ist darauf zu achten, dass alle Dienste sowie Daten von einem anderen Server bzw. DC übernommen werden. Das trifft auch für die FSMO-Rollen zu. Falls der FSMO-Rolleninhaber ausgetauscht werden sollte, gilt es die FSMO-Rollen entweder durch die grafische Oberfläche oder durch das im Betriebssystem enthaltene Kommandozeilentool NTDSUTIL manuell zu verschieben.

Das händische verschieben der Rollen hat den Vorteil, dass der Administrator bestimmen kann auf welchen DC die Rollen verschoben werden. Somit weiß der Administrator genau, auf welchem DC sich die Rollen befinden. Ein weiterer Vorteil des manuellen Verschiebens wäre, falls ein Unternehmen AD-lastig arbeitet und die FSMO-Rollen somit mehr beansprucht werden, kann der Administrator die Rollen auf eine leistungsfähige Maschine verschieben oder ggf. auf mehrere DCs verteilen.

Die Rollen müssen aber nicht beim Herunterstufen des Rolleninhabers zwingend manuell verschoben werden. Denn die FSMO-Rollen werden mit Ausführen von DCPROMO seit Windows 2000 RTM, also seit der Einführung des Active Directory, während des DCPROMO-Vorgangs automatisch auf einen anderen DC übertragen. Die Rollen können aber nur dann einem anderen DC übergeben werden, wenn das DNS ordnungsgemäß funktioniert, sowie der Rolleninhaber Verbindung zur Domäne und somit zu seinen Replikationspartnern hat. Dabei geht der Rolleninhaber folgendermaßen vor:

• Wurden die FSMO-Rollen vor dem herunterstufen nicht manuell verschoben, wird das „Operational Attribute“ GiveAwayAllFsmoRoles gesetzt. Das veranlasst den Rolleninhaber dazu, andere DCs ausfindig zu machen damit die Rollen die er trägt, auf einen anderen DC übertragen werden können.

• Für die Wahl des zukünftigen Rolleninhabers werden die folgenden Regeln angewendet:
  
  - Bevorzugt wird ein DC am gleichen Standort ausgewählt.
  - Es wird ein DC zu dem eine RPC-Verbindung besteht gesucht.
  - Es wird ein Server verwendet, zu dem eine asynchrone Verbindung (z.B. über das SMTP-Protokoll) existiert.

• Natürlich können dabei die drei domänenspezifischen Rollen RID-Master, PDC-Emulator sowie Infrastrukturmaster nur innerhalb der Domäne verschoben werden.

• Die beiden gesamtstrukturweiten Rollen Schemamaster sowie Domänennamenmaster können auf jeden DC in der Gesamtstruktur verschoben werden. Dabei spielt es keine Rolle, in welcher Domäne sie sich befinden.

Erreicht der Rolleninhaber während des Herunterstufens keinen weiteren DC, so schlägt zum einen das automatische Verschieben der Rollen und zum anderen das Herunterstufen fehl.

Wird der Rolleninhaber durch die erzwungene Herabstufung mit DCPROMO /Forceremoval heruntergestuft, so erhält der Administrator ab Windows Server 2003 SP1 für jede Rolle die der DC inne hat, eine Warnmeldung. Diese Rollen müssen dann im Nachhinein auf einem anderen DC offline übertragen werden.

Der Nachteil des automatischen Verschiebens der Rollen ist die nicht Vorhersagbarkeit der Ziel-DCs auf die die FSMO-Rollen verschoben werden (Ausnahme es existieren nur genau zwei DCs).

Doch auch bei dieser Variante müssen die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen ab Windows Server 2003 (wie z.B. ForestDNSZones und DomainDNSZones) manuell auf einen anderen DC verschoben werden. Diese werden nicht automatisch auf einen anderen DC übertragen. Näheres dazu erläutert der folgende Artikel: