Registrierungsrichtlinien auch ohne Änderung übernehmen - Niemals

Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie
"Registrierungsrichtlinienverarbeitung konfigurieren" -> Gruppenrichtlinienobjekte auch ohne Änderung verarbeiten

Das BSI und auch diverse andere Schablonen möchten, das für die genannte Richtlinie die Checkbox aktiviert konfiguriert wird. Es soll der Sicherheit dienen und das System immer und bei jedem GP Prozess auf den Zustand zurücksetzen, den der Administrator durch die Richtlinien vorgibt. Die unberechtigte Angst ist, das das System zur Laufzeit manipuliert wurde.

ÜBERRASCHUNG!

Das System kann von einem Benutzer nicht manipuliert werden. DAS IST DIE (verdammte) GRUNDBEDINGUNG für Gruppenrichtlinien in ihrer Kerndefinition der Infrastruktur, als sie Ende der 90er des letzten Jahrtausends konzipiert wurden. RICHTLINIEN SIND SICHER! (vor Benutzereingriff) im Gegensatz zu NT4 Systemrichtlinien, aber das ist eine andere Technik und ganz andere Geschichte.

Die wichtigste Änderung, aus Sicht von NT4, der Gruppenrichtlinie ist, das sie nicht vom Benutzer verändert werden kann. Die Registry Datenbank schützt sich über ACLs auf dem Schlüssel der Policies gegen Veränderung. Der Benutzer hat dort nur Lese-Rechte. Das ist unumstösslich. Desweiteren ist aus Performance Gründen eine Versionierung/History etabliert. Es kommt nur zu einem Übernahme Prozess, wenn es sich die Version ändert. Die Änderung muss aber in der Gruppenrichtlinie der Domäne stattfinden. Benutzer können Gruppenrichtlinien der Domäne nicht ändern. Nur Adminisrtratoren können das. Das System ist in sich konsistent, wenn Benutzer am System arbeiten.

Benutzer können nichts manipulieren, also muss nur ein Übernahme stattfinden, wenn sich etwas ändert. Solange sich nichts ändert ist es wie es muss, eine erneute Übernahme vorhandener, nie geänderter Daten ist unnötig.

gpupdate vs. gpupdate /force - Mythos #1 und #2 - Gruppenrichtlinien

Ich höre immer wieder das Argument, das es ein Schutz vor Benutzern ist, die in der Gruppe der LOKALEN Admnistratoren stecken. Damit diese nach einer unerwünschten Manipulation immer wieder auf dem Standard Regelwerk unterwegs sind.

ÜBERRASCHUNG!

Wenn Administratoren sich einmal erfolgreich gegen das System gewehrt haben, dann werden sie es wieder tun und wieder und wieder und wieder. Das Hase und Igel Spiel könnt ihr nicht gewinnen. Wer lokale Administratoren einsetzt, der muss sich um Sicherheit keine Gedanken machen. Er hat keine. Wer mich als lokalen Administrator in seinem Netzwerk hat, der sollte davon ausgehen, daß ich eine Batchdatei per Aufgabenplanung über einen Eventrigger starten kann, die per Script bei einem GP Prozess alle Settings direkt negiert und so definiert, wie ich sie gerne hätte. Dieser Job läuft natürlich mit System-Rechten, da ich ihn als Administrator etablieren durfte. gpupdate /force ist keine Lösung!

Es gibt neben dem Performance Theman einen viel wichtigeren Grund, das /force auf der Client Side Extension Registry zu unterlassen. Es geht um die Art, wie der Übernahme prozess funktioniert.

ÜBERRASCHUNG!

Der Übernahme Prozess löscht und fügt alles wieder neu hinzu. Die Integration erfolgt nicht additiv. Es werden nicht nur die 2, 3 Werte hinzugefügt, die fehlen oder einer gelöscht, Nein! Das Prozess wirft alles weg und übernimmt alles erneut. Achtung! Für einen kurzen Moment ist das System, Richtlinien frei!

Bekannte Probleme:

• RDP Verbindungen wurden bei gpupdate getrennt und wieder hergestellt. XP hatte da große Probleme. Die Korrektur erfolgte mit späteren RDP Versionen, die einfach die Zeittoleranz für den Diconnect erhöhten.
• Das Betriebssystem holt sich Updates von Microsoft direkt unkontrolliert aus dem Internet, obwohl es per GPO verboten ist und per GPO ein WSUS definiert ist, inkl. Zugriff auf Microsoft Internetadressen verhindern. Der Update Dienst ist für eine Millisekunde ohne Richtlinie, wenn er in dem Moment startet, fragt er bei Microsoft nach Updates.
• Homedrives, die per Administrativer Vorlage in der RDP Farm definiert wurden, diconnecten kurzfristig die SMB Verbindungen und stellen alle SMB Connections wieder neu her. In der großen Farm des Kunden hat es das Storage "zerlegt", weil diese durch Millionen Reconnnects binnen MIllisekunden "gestorben" ist. Praktisch ein Denial of Service durch gpudpate

Wie verhindert man dieses unerwünschte Fehlverhalten?

• Die genannten Einstellungen gehören nicht in die Gruppenrichtlinie.
• Die Registry Settings werden per Deployment oder per GPP Registry in das System integriert

Die Werte stehen durch geänderte Technik trotzdem an identischer Stelle im Client, wie bei der Übergabe durch die Richtlinien, sie werden aber nicht mehr durch den Update Prozess gesteuert. Somit werden sie nicht mehr gelöscht und neuerstellt, sondern bleiben immer gesetzt. Der Nachteil ist, sie sind nicht mehr löschbar durch den Automatismus der Richtlinie. Löschen ist nun ein aktivier Deployment Prozess.