Vorsicht Falle - hast Du die Sicherheits-Basisrichtlinien von Microsoft im Griff?

20.01.2026 20.01.2026

Krähe mit Hut

Ich habe immer mal wieder das "Vergnügen", neue Domänencontroller (DC) zu installieren, beispielsweise im Rahmen der Veröffentlichung neuer Betriebssystemversionen. Aktuell ist dies Windows Server 2025.

Nun habe ich das schon in diversen Umgebungen erfolgreich durchgeführt. In einer Umgebung bin ich jedoch auf ein Problem gestoßen, das potenziell größere Auswirkungen haben kann. Dieses stelle ich in der Folge kurz dar.

Das Phänomen - endloser Betriebssystem-Start

Wie üblich, habe ich eine neue virtuelle Maschine bereitgestellt (VMware) und die Rolle "Active Directory-Domänendienste" installiert und konfiguriert. Um die Konfiguration zu übernehmen, muss der Server neu starten. Es ist durchaus normal, dass Domänencontroller gerade beim ersten Start etwas länger brauchen, bis die Anmeldemaske angezeigt wird. Allerdings blieb der Server hier bei der Verarbeitung der Gruppenrichtlinien hängen und auch nach Stunden bewegte sich nichts mehr. Dementsprechend war der Server so nicht nutzbar.

Problemanalyse

Um der Ursache auf die Schliche zu kommen, habe ich verschiedene Tests durchgeführt. Meine Annahme war, dass irgendeine Gruppenrichtlinie das Problem verursacht, zumal der Server reproduzierbar bei der gleichen Gruppenrichtlinie hängen blieb. Die Richtlinie selbst konnte ich jedoch bereits ausschließen, da diese nur einige nicht relevante Registry-Einstellungen setzte und auf allen anderen Servern problemlos verarbeitet wurde.

Versuch 1: Deaktivierung der Netzwerkkarte im Hypervisor

Als erstes habe ich die Netzwerkkarte der virtuellen Maschine deaktiviert. Das Verhalten änderte sich dadurch, wenn auch nicht zufriedenstellend. Nun blieb die virtuelle Maschine beim Schritt "Computereinstellungen werden übernommen" für ca. 1 Stunde hängen. Danach wurde jedoch zumindest wieder die Anmeldemaske angezeigt. Die Dauer war reproduzierbar, es deutete also auf irgendeinen Standardwert für eine Zeitüberschreitung hin.

Für Gruppenrichtlinien liegt dieser Wert jedoch üblicherweise bei 10 Minuten. Daraus schloss ich, dass die problematische Einstellung bereits auf dem System angekommen war und anders entfernt werden musste.

Versuch 2: Löschung der lokal gespeicherten Gruppenrichtlinien

Der Großteil der Gruppenrichtlinieneinstellungen wird als Wert in der Registry gespeichert. Dementsprechend lassen sich diese recht einfach wieder entfernen. Hierzu muss der Inhalt des folgenden Pfads gelöscht werden:

HKEY_LOCAL_ MACHINE\Software\Policies\Microsoft

Der anschließende Neustart brachte jedoch keine Besserung. Es musste also eine Einstellung sein, die nicht in der Registry gespeichert wird.

Versuch 3: Deaktivierung aller zusätzlichen Gruppenrichtlinien in der OU "Domain Controllers"

Da der Server bis zur Installation der Serverrolle problemlos funktionierte und auch alle Mitgliedssysteme problemlos funktionierten, musste es sich um eine Richtlinie handeln, die speziell auf Domänencontroller angewendet wird. Dementsprechend habe ich alle zusätzlichen Gruppenrichtlinien deaktiviert. Die Standardrichtlinien ("Default Domain Policy" und "Default Domain Controllers Policy") blieben aktiviert, da diese nicht modifiziert worden waren.

Auch hier brachte ein Neustart keine Besserung. Es musste also eine Einstellung sein, die entweder explizit gegensätzlich konfiguriert werden muss ("Deaktiviert" statt "Aktiviert") oder so tief im System eingebunden ist, dass sie sich nicht mehr einfach entfernen lässt.

Versuch 4: Deinstallation der Serverrolle

Um die problematische Richtlinie einzugrenzen, habe ich als nächstes die Serverrolle deinstalliert. Und siehe da: der Server startete wieder normal. Es musste also eine Richtlinie explizit für die Domänencontroller sein. Und dies brachte mich auf die Sicherheits-Basisrichtlinien von Microsoft.

Was sind die Sicherheits-Basisrichtlinien?

Hierbei handelt es sich um vordefinierte Gruppenrichtlinien, die mit einem Skript importiert werden können. Diese werden von Microsoft unter dem Oberbegriff "Security Compliance Toolkit" kostenlos bereitgestellt und können aus dem Download Center heruntergeladen werden. Sie dienen zur Härtung des Betriebssystems und der Apps gegen typische Angriffsvektoren und schließen potenzielle Schwachstellen.

Sicherheits-Basisrichtlinien sind für folgende Betriebssysteme und Applikationen verfügbar:

Windows (Endgeräte)
Windows Server
Edge (Browser)
Office LTSC/Microsoft 365 Apps

Die Richtlinien werden separat für jedes Betriebssystem bzw. Applikation veröffentlicht, sind jedoch grundsätzlich aufwärts- und abwärtskompatibel. Aktualisierungen werden in unregelmäßigen Abständen veröffentlicht und müssen dann erneut importiert werden. Die Richtlinien können entweder über Active Directory verteilt oder auch lokal auf einem isolierten Server importiert werden.

Schon gewusst? Mit Windows Server 2025 ist es nicht mehr nötig, die Basisrichtlinien zu importieren. In WS2025 ist die Lösung "OSConfig" integriert, mit der auf einfache Weise Richtlinien direkt aktiviert werden können. Weitere Infos findest Du im offiziellen Artikel.

Ein wichtiger Teil: die virtualisierungsbasierte Sicherheit

Die Basisrichtlinien teilen sich in mehrere Gruppenrichtlinienobjekte auf, die unterschiedliche Bereiche konfigurieren. Ein Teil davon ist die virtualisierungsbasierte Sicherheit (VBS), die nicht nur für Domänencontroller, sondern auch generell aktiviert werden kann. Es gibt jedoch eine eigene Richtlinie speziell für Domänencontroller.

VBS wird von allen gängigen Virtualisierungsplattformen (z.B. VMware, Hyper-V) unterstützt, muss aber explizit für die virtuelle Maschine aktiviert werden, wenn es genutzt werden soll. Und hier liegt der Stolperstein, der bei mir aufgetreten ist.

Stolperstein: in Windows aktiviert, aber nicht im Hypervisor

Die Basisrichtlinie, die VBS auf Domänencontrollern einschaltet, war auf die Organisationseinheit für die Domänencontroller verknüpft. Die neue virtuelle Maschine, die ich für den Domänencontroller eingerichtet habe, war jedoch nicht entsprechend konfiguriert. In VMware muss hierzu bei Erstellung der VM oder nachträglich ein Haken in der Konfiguration gesetzt werden:

Interessanterweise hatte ich dieses Fehlerbild in anderen Umgebungen nicht bzw. es äußerte sich anders. Dort war ebenfalls die Richtlinie verknüpft und die Hypervisor-Einstellung nicht aktiv. In diesen Fällen gab es bei einer Gruppenrichtlinienaktualisierung mittels gpupdate /force eine Fehlermeldung:

Ereignis-ID: 1085, Quelle GroupPolicy
Fehler beim Anwenden der "{F312195E-3D9D-447A-A3F5-08DFFA24735E}"-Einstellungen. (...)

Mit etwas Recherche findet man heraus, dass dies ebenfalls auf die Richtlinie für die virtualisierungsbasierte Sicherheit zurückzuführen ist. Entfernt man die Verknüpfung, verschwindet der Fehler.

Lösung(en)

Ich habe zum Test zunächst versucht, die Richtlinie für den neuen Server abzuschalten und diesen anschließend wieder zum Domänencontroller hochzustufen. Nach dem Neustart ergab sich jedoch wieder das gleiche Bild: endloser Start. Da der Server noch nicht aktiv genutzt wurde, habe ich an der Stelle abgekürzt und den Server komplett neu installiert. Das erschien mir das einfacher. 😉

Weitere Lösungsansätze sind:

Deaktivierung/Entfernung der Richtlinie (aus Sicherheitssicht natürlich nicht empfohlen)
Aktivierung der Option im Hypervisor, BEVOR die Rolle "Active Directory-Domänendienste" installiert wird

Tipp: Detaillierte Statusmeldungen aktivieren

Standardmäßig zeigt Windows nur sehr grob an, welche Phasen das System beim Start durchläuft (bspw. Verarbeitung von Skripten, Anwendung von Registry-Einstellungen, Gruppenrichtlinien, usw.). Dies kann die Fehlersuche in so einem Fall erheblich erschweren, da man nicht sieht, in welcher Phase das System stehen bleibt.

Es ist daher empfehlenswert, für alle Systeme die Einstellung "Äußerst detaillierte Statusmeldungen anzeigen" zu aktivieren. Damit zeigt Windows genauer an, was in dem Moment verarbeitet wird. Dadurch lassen sich bereits erste Rückschlüsse auf die potenzielle Fehlerquelle ziehen. Die Einstellung befindet sich hier: