serverseitig lokale Client-Sicherheitsrichtlinien auslesen

[xMiguelx 10]

Hallo,

 

ich bin neu hier und habe bisher keinen Beitrag finden können, der beschreibt, wie man serverseitig von mehreren Domain-Clients die lokalen Sicherheitsrichtlinien ausliest.

 

Es geht darum, dass wir endlich einmal in unserer Firma alle Richtlinien über das Active Directory gleichziehen wollen.

Wie es aber oft so ist, gibt es halt auch bei uns Besonderheiten bei bestimmten Personen und Computern. Um nun nicht in die Situation zu kommen, dass wir serverseitige Richtlinien einstellen und manche Leute nach der nächsten Anmeldung oder dem nächsten Neustart nicht mehr arbeiten können, weil sie eben doch Zugriff auf dies und das benötigen, würde ich gerne vorher eine IST-Aufstellung vornehmen.

Ob nun VBS, kixtart, AutoItScript oder sonstwas mir dabei hilft, spielt dabei keine Rolle. Ich habe mit allem schon gearbeitet, nur für dieses Thema nichts gefunden, und mir fehlt die Zeit zum Selbstschreiben.

Die Landschaft besteht aktuell aus Windows 2000, Windows XP und einigen Windows 7 Clients. Die Server inkl. Domain Controller sind alle Windows 2003.

Wenn also jemand weiß, wie ich von einem 2003er Server aus die Infos, die ich an jedem Client über die Verwaltung der lokalen Sicherheitsrichtlinien auslesen kann, auslese, wäre das wirklich toll.

 

 

 

Vielen Dank schonmal im Voaus,

Miguel

[zahni 554]

Gegenfrage: Warum sollten diese Einstellungen gegenüber dem Standard verstellt sein ? Normalerweise gibt es für normale User keinen Grund die zu verändern. Zumal die das mit Bentzerrechten eh nicht können.

 

-Zahni

[xMiguelx 10]

Hallo Zahni,

 

Deine Frage ist natürlich berechtigt. Geändert haben die Benutzer selbst auch nichts, nur wurden im Laufe der Zeit an manchen Clients Ausnahmeeinstellungen vorgenommen - Selbstverständlich durch die Administratoren. Da ich neu in der IT-Abteilung der Firma bin, meine Aufgabe unter anderem ist saubere Gruppenrichtlinien einzuführen und ich befürchte, dass die irgendwann einmal getätigten LOKALEN SICHERHEITSRICHTLINIEN ihre Berechtigung hatten, um den Leuten das Arbeiten zu ermöglichen, ist es für mich wichtig, vorher einen IST-Stand zu bekommen.

 

Den Soll-Stand über die Gruppenrichtlinien habe ich bereits definiert.

Wenn ich das aber so einstelle, wie es von mir vorgeschlagen und auch bereits abgesegnet ist, dann - so befürchte ich - wird ein Mehraufwand durch Nacharbeit auf mich zukommen.

Es geht dabei quasi um ein einmaliges Audit-Script.

 

Ich habe heute bereits mit der PowerShell ziemlich viel realisieren können.

WMI liefert zwar nicht in jedem Fall saubere Daten, weil einfach zuviel in der Vergangenheit gefuscht wurde, aber das Auslesen der Registrierung tut das übrige.

 

Mein Anliegen ist eigentlich bloß, das Rad nicht neu erfinden zu müssen, denn solche Scripte gibt es sicherlich zu genüge im Netz - Deswegen diese Anfrage danach.

 

 

 

VG,

Miguel

[dmetzger 10]

Hilft vielleicht das hier:?

 

"secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose" (ohne An- und Abführung).

[xMiguelx 10]

Leider nicht wirklich.

 

Falls lokal auf Clients etwas anders eingestellt ist - was mir niemand genau sagen kann - würde ich gerne diese Einstellungen auslesen. Vielleicht lassen sich dadurch neue Gruppenrichtlinien ableiten, die zuvor nicht bedacht wurden.

 

Die Wiederherstellung auf die Default-Richtlinien bzw. auf einen bestimmten Sicherungspunkt ist dabei keine Lösung. Zumal kann gibt es sogar vereinzelt Clients, bei denen der Wiederherstellungsdienst abgeschaltet ist.

 

 

Totzdem Danke

[Dukel 454]

Wieso nicht doch die neuen GPO's testen?

 

Neue OU erstellen und konfigurieren.

Danach einen Client (oder Clientgruppen, wenn diese ähnlich bestückt sind) in diese OU verschieben. Alle Anwendungen und ggf. korrigieren.

 

Selbst wenn du Ausnahmen finden solltest mit Lokalen Anpassungen, was machst du dann mit denen? Testen ob diese wirklich noch benötigt werden und wenn ja eine neue GPO erstellen?

Auch wenn Sys-Admins vorher Richtlinien eingerichtet haben, wenn diese nicht begründen können, warum würde ich davon ausgehen, dass dies nicht benötigt wird.

Evtl. sind diese Richtlinien als Workaround oder weil man zu Faul war eine richtige Lösung zu suchen eingerichtet worden.