Daniels Tagesmeldungen

Ich habe auf einer Testsystem mit dem Betriebssystem Windows Vista, welches unter Microsoft Virtual PC 2007 SP1 läuft, OpenOffice 3.0 installiert, da ich eine Einstellung, die ich auf meinem Hauptystem nicht aktivieren möchte, dokumentieren wollte.

Nun musste ich für die Konfiguration der Einstellung einen Wert berechnen, Wie für mich als Tastatur-"Junkie" üblich, gab ich im Suchfeld des Startmenüs den befehl "calc" ein. Nur wunrderte ich mich, dass die Tabellenkalkulation von OpenOffice gestartet wurde.

Um den Taschenrechner zu starten muss nun nach der Installation von OpenOffice der Befehl "calc.exe" oder der Titel "Rechner" aufgerufen werden, da die Tabellenkalkulation als Programm im Indexing einen Vorrang zum Dateinamen des Taschenrechners.

Ich habe gestern Abend bei den englischen Prüfungsfragen zum Buch den Begriff “Schattengruppen” gefunden und mir viel ein, dass ich so etwas selber bei eienr von mir betreuten Domäne einsetzte.

Als Schattengruppen bezeichnet man Gruppen, die alle User einer OU beinhaltet. Dieses ist zwar ganz nett, aber in der Regel werden schon mal Benutzer gelöscht oder auch hinzugefügt. Dabei muss daran gedacht werden, dass die Benutzer der entsprechenden Gruppe hinzugefügt werden.

Ich habe mir nun mal Gedanken gemacht, wie ich so etwas automatisieren kann. Nach meinen Recherchen bin ich nun auf den richtigen Befehlssatz gestoßen:

dsquery user * “OU=test, DC=TESTDOMAIN, DC=local” | dsmod group “CN=Tester, OU=Gruppen, OU=TESTDOMAIN, DC=local” -chmbr

Was macht dieser:
Als erstes wird durch den Befehl ausgelesen, welche Benutzer in der OU test der Domäne testdomain.local vorhanden sind. Anschließend werden durch das Attribut chmbr in Zusammenhang mit dem Befehl dsmod alle aktuellen Mitglieder gelöscht und anschließend die ermittelten Benutzer hinzugefügt.

Man kann nun noch 2 weitere Optionen setzen:
-c würde den Befehl trotz einer auftretenden Fehlermeldung weiterdurchführen. In wie weit dieses Sinn macht muss jeder Verantwortliche selbst für sich wissen.

> c:\log\auto_group.txt erzeugt eine Log-Datei, die man sich als Verwalter des Systems bei Gelegenheit oder Problemen einmal ansehen kann. Da man meistens dieses Befehlssatz und beaufsichtigt durchführen lässt, bietet diese Erweiterung des Aufrufs die Möglichkeit der Kontrolle.

Ich habe dieses Aufruf nun mehrfach getestet bzw. eine Batchdatei erstellt, die dieses mit ca. 15 Gruppen durchführt. Dabei sind bei meinen Versuchen noch keine Fehler aufgetreten, die dokumentiert worden sind.

Im Zusammenhang mit meiner Zertifizierungsvorbereitung zum Thema Active Directroy habe ich mich auch aus dienstlichem Hintergrund am Freitag sehr stark mit Gruppenrichtlinien beschäftigt.

Der Regelfall für eine Gruppenrichtlinie (GPO) ist, in dem man seine entsprechenden Einstellungen konfiguriert und die Ricktlinie an die Domäne oder eine Organisationseinheit (OU) bindet.

Mehrere Passwortrichtlinien können inzwischenzeit unter Windows Server 2008 und der entsprechenden Domänenfunktion erstellt und verwaltet werden.

Nun trat allerdings das Problem auf, daß mehrere Richtlinien verschachtelt werden mussten und nicht jeder Anwender jede Group Policy erhalten sollte. Es gab nun mehrere Varianten:

Variante A: für jede Gruppenrichtlinie eine eigene OU
Wenn man nur eine Gruppenrichtlinie einsetzt, okay. Leider ist dieses allerdings selten der Fall.

Variante B: Vererbung in bestimmten OUs unterbrechen
Durch die Beendigung der Vererbung ist es schwierig Änderungen in der gesammten Directory-Struktur unterzubringen. Ausserdem können bei der Auflösung der Vererbung weitere Richtlinien beendet werden, die händisch nach gesteuert werden müssen.

Variante C: WMI-Filterung
Vielleicht kann man es durch einen WMI-Wert filtern, welcher Client die Richtlinie verarbeiten soll. Zum Beispiel wäre eine Richtlinie denkbar für alle Systeme, die mit Windows XP arbeiten erhalten Richtlinie 1 sowie alle Systeme, die mit Windows Vista arbeiten, erhalten Richtlinie 2.

Dieses funktioniert so lange gut, bis 2 Faktoren erreicht sind:

Faktor 1: Die WMI-Filterung verlangsamt das Start des Rechners so stark, dass die Anwender sich beschweren, da das Auslesen der WMI-Daten Rechnerleistung benötigt.

Faktor 2: Es werden noch Windows 2000-Systeme genutzt. Bei diesen Systemen ist eine WMi-Filterung nicht möglich, so dass beide Richtlinien auf dem System greifen würden entsprechend der Rangfolge

Variante D: Sicherheitsfilterung

Über diesen Weg ist es möglich Domänen-Gruppen zu berechtigen und entsprechend die User bzw. Computer zu steuern, die diese Richtlinie abarbeiten soll. Ein weiterer Vorteil ist, dass ein Helpdesk ohne Kenntnis über Gruppenrichtlinien diese Verwalten kann in der für Sie bekannten Form per SnapIn für die MMC über “Active Directory Benutzer und Computer”