Gruppenrichtlinien und Sicherheitsbaselines

Gruppenrichtlinien werden im Verzeichnis entworfen und auf Servern wirksam — das sind zwei Tätigkeiten mit zwei verschiedenen Fragen. Dieses Modul behandelt die zweite: welche Richtlinie auf diesem Server gilt, warum sie gilt und ob sie überhaupt angekommen ist. Dazu die Stellen, an denen die Erwartung nicht stimmt: ein Aktualisierungslauf, der eine von Hand verstellte Einstellung nicht korrigiert, weil sich für ihn nichts geändert hat, und ein Runbook, das auf ein Ereignis wartet, das mangels eingeschalteter Überwachung nie entsteht.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Die Sicht des Serveradministrators

Gruppenrichtlinien werden im Verzeichnis entworfen und auf Servern wirksam. Das sind zwei verschiedene Tätigkeiten mit verschiedenen Fragen. Wer einen Server betreibt, muss selten eine Richtlinie schreiben — und ständig beantworten, welche auf diesem Server gilt, warum sie gilt und ob sie tatsächlich angekommen ist.

AbgrenzungDer Track active-directory behandelt den Entwurf: Struktur, Vererbung im Verzeichnis, Verknüpfung an Standort, Domäne und Organisationseinheit. Hier geht es um die andere Seite — den Server, auf dem am Ende etwas gilt oder eben nicht, und die Werkzeuge, mit denen man das feststellt statt es anzunehmen.

Der praktische Anlass ist fast immer derselbe: Eine Einstellung wurde geändert und wirkt nicht, oder eine Einstellung wirkt und niemand weiß, woher sie kommt. Beide Fragen lassen sich auf dem Server beantworten, ohne dass jemand die Verzeichnisstruktur kennen muss.

Die Reihenfolge, in der Richtlinien greifen

Richtlinien werden in einer festen Reihenfolge angewendet. Was später kommt, überschreibt was früher kam — der letzte Schreiber gewinnt.

Lokal, Standort, Domäne, Organisationseinheit — und innerhalb einer Ebene entscheidet die Verknüpfungsreihenfolge.

Lokale Richtlinie: Auf dem Server selbst gesetzt. Wird zuerst angewendet und von allem Folgenden überschrieben.
Standort: Für alle Rechner eines Active-Directory-Standorts.
Domäne: Für alle Rechner der Domäne.
Organisationseinheit: Von oben nach unten; die unterste gewinnt.
Ausnahmen: Erzwungen dreht die Richtung um, Vererbung deaktivieren blockiert von oben — beide brechen die einfache Regel.

Warum die lokale Richtlinie trotzdem zähltSie steht am Anfang und wird von jeder Domänenrichtlinie überschrieben, die dieselbe Einstellung setzt. Für Einstellungen, die keine Domänenrichtlinie anfasst, bleibt sie aber wirksam — und genau dort sammelt sich über Jahre an, was jemand einmal von Hand gesetzt hat. Bei einem Server mit unerklärlichem Verhalten ist die lokale Richtlinie einer der ersten Orte, an dem man nachsieht.

Zwei Sonderfälle brechen die Regel, und beide sind sichtbar, wenn man danach sucht. Erzwungen an einer Verknüpfung sorgt dafür, dass eine höhere Ebene nicht mehr von einer tieferen überschrieben wird — die Richtung dreht sich um. Vererbung deaktivieren an einer Organisationseinheit blockiert alles von oben, außer erzwungenen Verknüpfungen. Wo beides gleichzeitig im Spiel ist, lässt sich die geltende Reihenfolge nicht mehr aus der Struktur ablesen, sondern nur noch aus dem Bericht auf dem Server. Genau dafür gibt es ihn.

Warum eine Änderung nicht ankommt

Zwischen der Änderung im Verzeichnis und ihrer Wirkung auf dem Server liegen mehrere Schritte, und jeder kann scheitern. Die Fehlersuche wird deutlich kürzer, wenn man sie in dieser Reihenfolge abläuft.

Wird die Richtlinie auf diesen Server überhaupt angewendet — oder filtert eine Sicherheitsgruppe sie weg?
Ist sie angewendet, aber von einer späteren überschrieben?
Hat der Server sie seit der Änderung überhaupt neu abgeholt?
Braucht die Einstellung einen Neustart oder eine neue Anmeldung, um zu wirken?

Der dritte Punkt ist der häufigsteRichtlinien werden im Hintergrund in Abständen aktualisiert, nicht sofort. Wer eine Änderung macht und zwei Minuten später auf dem Server nachsieht, sieht den alten Zustand — und schließt daraus auf einen Fehler in der Richtlinie. Ein Aktualisierungslauf beantwortet die Frage in einem Schritt und kostet nichts.

Die Einstellung, die nicht ankommt

Szenario

Eine neue Richtlinie soll auf allen Anwendungsservern ein Benutzerrecht setzen. Nach zwei Tagen meldet das Team, dass es auf der Hälfte der Server nicht wirkt. Die Richtlinie ist an der richtigen Organisationseinheit verknüpft.

Anforderungen

Die Ursache soll ohne Zugriff auf das Verzeichnis eingegrenzt werden.
Das Ergebnis soll für alle betroffenen Server gelten.

Schritte

Auf einem betroffenen Server gpresult /r ausführen — steht die Richtlinie unter den angewendeten oder unter den gefilterten Objekten?
Befund: Sie steht unter den gefilterten, mit dem Hinweis auf die Sicherheitsfilterung.
Die Sicherheitsgruppen des Computerkontos im selben Bericht ablesen und mit der Filterung vergleichen.
Ergebnis: Die betroffenen Server sind nicht Mitglied der Gruppe, auf die gefiltert wird.
Ursache benennen: Die Server wurden nach dem Anlegen der Gruppe gebaut und nie aufgenommen — und ein Computerkonto übernimmt eine neue Gruppenmitgliedschaft erst nach einem Neustart.

Merksatz: Die Richtlinie war nie fehlerhaft. Der Bericht auf dem Server hat zwei Fragen in einem Schritt beantwortet — ob sie angewendet wurde und warum nicht —, ohne dass jemand die Verzeichnisstruktur öffnen musste.

Was `gpupdate` tut und was nicht

gpupdate: Wendet nur geänderte Richtlinieneinstellungen an. Der Normalfall.
gpupdate /force: Wendet alle Einstellungen erneut an, unabhängig davon, ob sie sich geändert haben.
gpupdate /target:computer: Beschränkt den Lauf auf die Computer- oder die Benutzerseite.
gpupdate /sync: Sorgt dafür, dass die nächste Anwendung im Vordergrund synchron läuft — beim Start beziehungsweise bei der Anmeldung.
gpupdate /boot und /logoff: Lösen Neustart beziehungsweise Abmeldung aus, wenn die Einstellungen das verlangen.

Der Unterschied, der Zeit kostetOhne /force wird nur angewendet, was sich geändert hat. Hat jemand auf dem Server von Hand einen Wert verstellt, den die Richtlinie schon vorher gesetzt hatte, sieht die Richtlinie keine Änderung — und korrigiert ihn nicht. Genau dafür gibt es /force. Umgekehrt gilt: /force erzeugt deutlich mehr Last auf den Domänencontrollern; als Standard in einem Skript über hunderte Server ist es die falsche Wahl.

Der Punkt zu /sync verdient Beachtung: Manche Einstellungen — Ordnerumleitungen, Softwareinstallation, Skripte — können nur im Vordergrund angewendet werden, also beim Start oder bei der Anmeldung. Ein Hintergrundlauf ändert daran nichts, egal wie oft man ihn wiederholt.

Der Bericht, der die Frage beantwortet

Statt zu raten, welche Richtlinie gewonnen hat, lässt sich der resultierende Satz von Richtlinien abfragen. Er zeigt, was tatsächlich angewendet wurde, was gefiltert wurde und woher jede Einstellung stammt.

gpresult /r — Zusammenfassung: angewendete und gefilterte Richtlinienobjekte, Sicherheitsgruppen des Kontos.
gpresult /h bericht.html — der vollständige Bericht als HTML, mit der Herkunft jeder Einstellung.
gpresult /scope computer — nur die Computerseite, ohne den Benutzeranteil.
gpresult /s <Server> /h bericht.html — für einen entfernten Server; braucht laut Dokumentation passende Firewallregeln.

Der HTML-Bericht ist das eigentliche WerkzeugDie Textzusammenfassung sagt, welche Objekte angewendet wurden. Der HTML-Bericht sagt bei jeder einzelnen Einstellung, welches Objekt sie gesetzt hat. Damit lässt sich die Frage „woher kommt dieser Wert“ ohne Vermutung beantworten — und das ist die Frage, die bei einem übernommenen Server am häufigsten gestellt und am seltensten beantwortet wird.

Baselines schreibt man nicht selbst

Windows bringt laut Dokumentation über 3 000 Richtlinieneinstellungen mit. Nur ein Teil davon ist sicherheitsrelevant, und für jeden einzelnen müsste jemand die Auswirkung bewerten und einen Wert festlegen. Das ist der Grund für Sicherheitsbaselines.

Sicherheitsbaseline — Eine Gruppe von Microsoft empfohlener Konfigurationseinstellungen mit Erläuterung ihrer sicherheitsrelevanten Auswirkung — abgeleitet aus Rückmeldungen von Sicherheitsteams, Produktgruppen, Partnern und Kunden.

Die ausdrückliche EmpfehlungDie Dokumentation empfiehlt, eine breit bekannte und gut erprobte Standardkonfiguration einzusetzen, statt selbst eine Baseline zu erstellen. Die Begründung ist wirtschaftlich: mehr Flexibilität, geringere Kosten. Wer eine eigene Baseline schreibt, übernimmt damit die Pflege von tausenden Einstellungen über jeden Versionswechsel hinweg — eine Aufgabe, die kaum eine Organisation dauerhaft leisten kann.

Der Werkzeugkasten dazu

Microsoft liefert die Baselines mit zwei Werkzeugen aus, die im Betrieb mehr wert sind als die Baselines selbst.

Security Compliance Toolkit: Herunterladen, analysieren, testen, bearbeiten und speichern der empfohlenen Konfigurationen.
Policy Analyzer: Vergleicht Richtliniensätze gegeneinander, gegen die aktuelle lokale Richtlinie und gegen die Registry.
LGPO: Wendet eine Baseline auf die lokale Richtlinie an — der Weg für Server ohne Domäne.

Was der Vergleich sichtbar machtDer Policy Analyzer behandelt einen Satz von Richtlinienobjekten als Einheit und zeigt, ob Einstellungen darin doppelt vorkommen oder auf widersprüchliche Werte gesetzt sind. In einer über Jahre gewachsenen Struktur ist das regelmäßig ein unangenehmer Befund — und einer, den niemand durch Hinsehen findet. Zusätzlich lässt sich eine Momentaufnahme festhalten und später gegen eine neue halten: So wird sichtbar, was sich seit dem letzten Stand geändert hat.

Für den Betrieb ist der Vergleich gegen eine gespeicherte Momentaufnahme der nützlichste Teil. Er beantwortet die Frage, die nach jedem Wartungsfenster und nach jeder Störungsbehebung offen bleibt: Was ist seither anders? Ohne dieses Werkzeug lautet die Antwort „soweit wir wissen nichts“, und diese Formulierung hat schon viele Fehlersuchen in die falsche Richtung geschickt. Eine Momentaufnahme kostet Minuten und macht aus einer Vermutung eine Liste.

Server ohne Domäne

Nicht jeder Server ist Domänenmitglied. Server in einer entkoppelten Umgebung, in einer Randzone oder in einem abgeschotteten Netz bekommen keine Domänenrichtlinie — und brauchen trotzdem eine Konfiguration, die sich beschreiben und wiederherstellen lässt.

Für diesen Fall ist LGPO gebaut: Es überträgt eine Baseline in die lokale Richtlinie und macht sie damit auf einem einzelnen Server anwendbar. Der Unterschied zur Domänenrichtlinie bleibt: Es gibt keinen Mechanismus, der die Einstellung regelmäßig erneut durchsetzt. Was jemand von Hand ändert, bleibt geändert.

Die Folge für den BetriebBei diesen Servern ersetzt eine regelmäßige Prüfung die automatische Durchsetzung. Der Policy Analyzer vergleicht dafür den Ist-Zustand gegen die gespeicherte Baseline und liefert die Abweichungen. Ohne diese Prüfung ist die Aussage „dieser Server folgt der Baseline“ nur zum Zeitpunkt der Einrichtung wahr — und danach eine Behauptung.

Ein Zusatzaspekt betrifft die Wiederherstellung. Bei einem Domänenmitglied entsteht die Konfiguration nach einem Neuaufbau von selbst, sobald der Server der richtigen Organisationseinheit angehört. Bei einem Server ohne Domäne muss die Baseline erneut angewendet werden, und das setzt voraus, dass die Baseline-Dateien auffindbar sind und jemand den Ablauf kennt. Der Wiederanlaufplan eines solchen Servers ist deshalb länger als der eines Domänenmitglieds — ein Punkt, der bei der Aufwandsschätzung regelmäßig fehlt.

Die Überwachungsrichtlinie ist eine eigene Ebene

Was ein Server protokolliert, wird über die Überwachungsrichtlinie gesteuert — und die hat eine Besonderheit, die regelmäßig zu Verwirrung führt: Es gibt eine grobe alte Ebene mit neun Kategorien und eine feine mit Unterkategorien. Sie können einander widersprechen.

auditpol /get /category:* — was gilt auf diesem Server tatsächlich, je Unterkategorie?
auditpol /set /subcategory:"..." /success:enable /failure:enable — eine einzelne Unterkategorie setzen.
auditpol /backup /file:<Datei> — den Ist-Zustand sichern, bevor etwas geändert wird.
auditpol /restore /file:<Datei> — ihn zurückholen.

Warum das hierher gehörtEin Runbook, das auf eine bestimmte Ereigniskennung wartet, setzt voraus, dass die zugehörige Unterkategorie überwacht wird. Ob das der Fall ist, sagt weder die Richtlinie im Verzeichnis noch das Ereignisprotokoll — es sagt auditpol auf dem Server. Das ist die Verbindung zum Modul über Ereignisprotokolle und Beweissicherung: Was dort ausgewertet werden soll, muss hier eingeschaltet sein.

Zur Sicherung gehört ein Hinweis: auditpol /backup schreibt den Ist-Zustand in eine Datei, die sich zwischen Servern vergleichen lässt. Damit wird aus der Frage „protokollieren unsere Server einheitlich“ ein Textvergleich statt eines Rundgangs durch Oberflächen. Und wie überall im Betrieb gilt: Die Sicherung entsteht vor der Änderung, nicht danach — nach der Änderung sichert man den neuen Zustand und weiß nicht mehr, was vorher war.

Drift ist ein Messwert, keine Diagnose

Weicht ein Server von seiner Baseline ab, ist das zunächst nur eine Feststellung. Sie sagt nichts darüber, ob die Abweichung ein Fehler, eine begründete Ausnahme oder eine überholte Baseline ist.

Kurzcheck

Ein Bericht meldet für 40 von 200 Servern dieselbe Abweichung von der Baseline. Was ist der erste Schritt?

Klären, was die 40 gemeinsam haben — eine gleichartige Abweichung hat meist eine Ursache
Die Abweichung auf allen 40 Servern korrigieren, dafür ist die Baseline da
Die Baseline anpassen, weil 40 Server sie offenbar nicht erfüllen können

Treffer. Richtig. Dieselbe Abweichung auf einer klar abgegrenzten Teilmenge deutet auf eine Rolle, eine Anwendung oder eine bewusste Ausnahme hin — nicht auf 40 unabhängige Fehler.

Daraus folgt die Reihenfolge: erst die Abweichung erklären, dann entscheiden — korrigieren, als Ausnahme festhalten oder die Baseline ändern. Alle drei sind legitim, und nur die Entscheidung dazwischen macht aus einer Zahl eine Aussage.

Nützlich ist außerdem die Unterscheidung nach Herkunft der Abweichung. Eine Abweichung, die auf allen Servern einer Rolle auftritt, ist fast immer eine Anforderung dieser Rolle. Eine, die auf einem einzelnen Server auftritt, ist meistens ein manueller Eingriff — oft aus einer Störungsbehebung, die nie zurückgenommen wurde. Und eine, die nach einem Versionswechsel auf allen Servern gleichzeitig erscheint, ist meistens eine überholte Baseline: Die Einstellung heißt in der neuen Version anders oder existiert nicht mehr. Drei Muster, drei verschiedene richtige Antworten.

Die Ausnahme als Vertrag

Eine begründete Ausnahme ist kein Makel, sondern der Normalfall in jeder gewachsenen Umgebung. Gefährlich wird sie erst, wenn sie unsichtbar ist — dann ist sie von einem Fehler nicht mehr zu unterscheiden.

Was: Welche Einstellung weicht ab, und auf welchen Systemen?
Warum: Welche Anforderung macht die Abweichung nötig? Ohne Grund ist es keine Ausnahme, sondern ein Versäumnis.
Wer: Wer hat sie entschieden und trägt das Risiko?
Bis wann: Ein Ablaufdatum. Ohne das wird jede Ausnahme dauerhaft.

Die vierte Zeile ist die, die fehltEine Ausnahme ohne Ablaufdatum wird nie wieder geprüft — nicht aus Nachlässigkeit, sondern weil es keinen Anlass gibt, sie anzuschauen. Ein Datum erzeugt diesen Anlass. Läuft es ab und die Ausnahme ist weiterhin nötig, wird sie mit neuem Datum verlängert; das kostet fünf Minuten und hält die Liste ehrlich.

Praktisch reicht dafür eine Tabelle mit vier Spalten und keine eigene Anwendung. Der Wert liegt nicht im Werkzeug, sondern darin, dass es die Liste überhaupt gibt und dass eine Abweichung darin nachschlagbar ist. Ein Prüfbericht, der neben jeder Abweichung entweder eine Ausnahme oder nichts findet, trennt in Sekunden das Bekannte vom Neuen — und nur das Neue braucht Aufmerksamkeit. Ohne die Liste ist jeder Bericht gleich lang wie beim ersten Mal.

Was in die Übergabe gehört

gpresult /h einmal erzeugen und ablegen — der Ist-Zustand zum Zeitpunkt der Übernahme.→auditpol /backup — was protokolliert dieser Server, bevor jemand etwas ändert?→Prüfen, ob es lokale Richtlinieneinstellungen gibt, die keine Domänenrichtlinie überschreibt.→Die geltende Baseline benennen und die bekannten Ausnahmen samt Ablaufdatum festhalten.→Für Server ohne Domäne: die Prüfung gegen die Baseline terminieren, da es keine Durchsetzung gibt.

Der erste Punkt kostet einen Befehl und beantwortet später jede Frage der Form „war das schon immer so“.

Der PreisEine Baseline durchzusetzen bedeutet, dass etwas nicht mehr funktioniert, das vorher funktionierte — irgendetwas trifft es immer. Wer das nicht einplant, führt eine Baseline ein und nimmt sie nach der dritten Störung wieder zurück. Der tragfähige Weg ist derselbe wie bei Patchringen: eine kleine, repräsentative Gruppe zuerst, ein definiertes Abbruchkriterium, und erst danach die Breite.

Die Liste ergänzt die Übernahmeprüfungen aus den Modulen über Start, Beobachtbarkeit und Wiederherstellung. Alle vier zusammen sind an einem Vormittag je Server zu erledigen und beantworten die Fragen, die im Ernstfall unbeantwortbar werden: Wie komme ich heran, was kann er mir sagen, wie bekomme ich ihn zurück — und was gilt auf ihm eigentlich. Der letzte Punkt ist der, für den es kein Werkzeug gibt, das ihn nachträglich rekonstruiert.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität8 Primärquellen · zuletzt geprüft: 2026-09-04