Zentrale Steuerung und Vergabe von lokalen Sicherheitseinstellungen der Clients über die Optionen:



a.)       Eingeschränkte Gruppen

b.)       Systemdienste

c.)       Registrierung

d.)       Dateisystem

 

Add-On:          Well-known SID´s
Übersicht über die dem System bekannten und automatisch vergebenen SID´s von Benutzergruppen

 

 

 

Eingeschränkte Gruppen

 

Sie möchten einen Domänen-Benutzer von Hause aus in eine bestimmte Lokale Gruppe der Workstation integrieren? Dann bietet die Funktion der „Eingeschränkten Gruppe“ genau diese Möglichkeit.

 

Mit den Eingeschränkten Gruppen ist es möglich einen Benutzer der Domäne automatisch in die Lokale Gruppe der Hauptbenutzer, oder gar Lokalen Administratoren zu übernehmen, anstelle das die Domänen-Benutzer per Default automatisch auf die lokale Gruppe der Benutzer gemappt wird.

 

Der Vorteil besteht unter anderem darin den Benutzer mit mehr Rechten an seiner Workstation auszustatten, weil es evtl eine 3rd Party Software verlangt, oder der Benutzer einer ihrer Co-Administratoren ist, die sie gerne an den Workstations mit „Vollzugriff“ ausstatten möchten damit sie an allen Bereichen der Workstation im Falle einer Fehlers auch konstruktive Hilfe anbieten können, ohne diesen gleich die Domänen-Administratoren Kennwörter in die Hand zu geben.

 

So nett wie sich das anhört so gefährlich kann diese Option sein, denn die Einstellung der Eingeschränkten Gruppe ersetzt komplett die lokal vorhandene Konfiguration, bzw. entfernt ggfs. alle Benutzer aus der per Default vorhandenen Gruppe und setzt dort nur noch die Mitglieder ein, die auch in der Eingeschränkten Gruppe definiert sind, spätestens bei erneuter Anmeldung des Users, bzw. nach 90 Minuten, wenn die Sicherheitsrichtlinie per Default Verhalten an die Clients neu übermittelt wird.

 

Komplizierter Satz, einfaches Beispiel.

Ich mache Asterix und Obelix zu Lokalen Administratoren über die Funktion der Eingeschränkten Gruppe. Jetzt passiert folgendes, alle ehemaligen Mitglieder der Lokalen Administratoren werden aus dieser Gruppen entfernt und nur noch Asterix und Obelix sind lokale Admins … in diesem Moment haben wir gerade den Domänen-Administrator zu einem einfachen „Benutzer“ an den Workstations degradiert.

Man sollte also darauf achten, daß dir original vorhandenen Einstellungen erhalten bleiben und in der obigen Konfiguration nicht nur Asterix und Obelix hinzugefügt werden, sondern auch Administratoren. 


 

1. Beispiel:

Asterix und Obelix sind Mitglieder der globalen Gruppe Co-Admins, die ihre Zugriffe auf bestimmte Installationsverzeichnisse auf den Server regeln. Diese beiden Benutzer sollen Lokale Administratoren Rechte erhalten, zusätzlich soll automatisch jedes Mitglied dieser „Eingeschränkten Gruppe“ Mitglied der Co-Admins sein.


 

 



 

2. Beispiel:

Bei der Gruppe der „Hauptbenutzer“ ist es weniger kompliziert, da die Gruppe der „Poweruser“ nicht auf einen DC Server existieren und auch keine Default Mitgliedschaft für diese Gruppe existiert, somit kann auch keine vorhandene Mitgliedschaft ersetzt werden.

 


 

Die Gruppe Hauptbenutzer muss per Hand hinzufügt werden (manuell eintippen), da diese nicht über die „Durchsuchen Funktion“ gefunden werden kann. Allerdings ist das System so schlau trotz der unbekannten Gruppe keinen userenv -1000 Fehler zu generieren, da die Gruppe Hauptbenutzer und dessen SID (S-1-5-32-547) zu den sogenannten Well-know SID´s gehört und vom System als solche (bei richtiger schreibweise J) auch erkannt wird.
Eine Übersicht der  der dem System bekannten und automatisch vergebenen SID gibt es am Ende des Textes, oder hier:

 

 

3. Beispiel (beigesteuert von Norbert Fehlauer)
Oben wurde beschrieben dass man bei der Vergabe von Berechtigungen mittels der Eingeschränkten Gruppen vorsichtig sein muss, da diese die lokal definierten Gruppenmitgliedschaften ersetzen können. Allerdings kann man auch genau das gegenteilige Verhalten mittels dieser Funktion erreichen. Man kann mit den Eingeschränkten Gruppen auch Domänengruppen zu den lokalen Gruppen hinzufügen ohne dass die bereits konfigurierten Mitgliedschaften ersetzt werden. Dies ist zum Beispiel nützlich wenn man viele Notebook-Nutzer hat die auf ihren jeweiligen Computern lokale Administratoren sind. Oftmals kommen diese nämlich nach dem Studium „diverses dubioser“ Literatur auf die Idee sie müssten jetzt unbedingt alleinige Administratoren auf den Laptops sein und sperren damit den Domänen-Admin erstmal aus. Im Nachfolgenden Beispiel wird gezeigt wie man diese Konfiguration wieder rückgängig macht. Im Gegensatz zu den anderen beiden Beispielen nimmt man keine lokale sondern eine Domänengruppe und fügt diese der lokalen Gruppe der Administratoren hinzu.



Ab sofort werden die Domänen-Admins der Gruppe der Administratoren auf allen Computern in GPO Reichweite hinzugefügt ohne dass die dort vorhandenen Nutzer davon beeinflusst werden. 

 

 

Systemdienste

 

Mit dieser Option kann das Startverhalten der auf der Workstation vorhandenen Dienste geändert werden. Selbst wenn ein Benutzer das Recht hat die Startart zu ändern und einen Dienst deaktiviert, so ist es mit dieser Option möglich, den Dienst zentral wieder auf automatisch umzustellen, sodass dieser beim nächsten Reboot wieder mitläuft.
Zusätzlich kann die Berechtigung an diesem Dienst verändert, werden womit sich widerum steuern lässt, welcher Benutzer überhaupt das Recht hat diesen Dienst und dessen Startart zu verändern.
Leider können nur Dienste am Server zentral gesteuert werden, die auch dort lokal vorhanden sind. Zur Not muss ein „Dummy“-Eintrag für den Dienst erstellt werden, z.b.: mit instsrv.exe oder srvany.exe aus dem RessourceKit

Beispiel:

Nur Mitglieder der Gruppe Domänen-Administratoren, sollten den „Nachrichtendienst“ verwalten dürfen und die Startart ist auf „Automatisch“ festgelegt.

 


 

Auch hier ersetzen  die vorgenommenen Berechtigunsänderungen, die vorhandenen Sicherheitseinstellungen, die aktuell lokal auf dem System implementiert sind. (Administrator nicht vergessen)

 

 

 

Registrierung

 

An dieser Stelle können die lokal vorhandenen Berechtigungen innerhalb der Registry zentral geändert werden, die sonst nur per Management-by-Turnschuh und regedt32.exe geändert werden können.

In diversen Umgebungen ist es notwendig, das ein normaler Benutzer im Bereich von HKEY_LOCAL_MACHINE mehr Rechte benötigt, als dieses vom System per Default vorgesehen ist. Ein normaler User braucht unter reinen MS Bedingungen mit aktueller Software im gesamten Schlüssel HKLM nicht mehr als das Recht „Lesen“.

privater Kommentar:
Leider haben diverse Hersteller von Software das Rechte-System von Microsoft (das schon mit NT4 entwickelt wurde) überhaupt nicht verstanden und programmieren immer noch ohne Rücksicht auf Verluste wie unter Windows9x. Diese Software benötigt dann im laufenden Betrieb, oder oft zumindest für den Erststart im Bereich von HKLM Schreib-Rechte.
Unter 9x Bedingugnen stellt das kein Problem dar, denn dort ist jeder Benutzer „Lokaler Administrator“, aber unter Windows 2000/XP ist das eine große Stolperfalle.

Zur Kontrolle, in welchen Bereichen , in welchem Pfad erhöhte Rechte benötigt werden, greift man am Besten zu einem Programm wie regmon von Sysinternals, oder ähnlichen Alternativen.

Ist der Pfad erst mal bekannt, so kann dieser über die Richtlinien-Option „Registrierung“ beinflusst werden.
Auch hier gilt es wieder zu beachten, dass unter normalen Bedingungen die gesetzten Berechtigungen die lokal vorhandenen komplett ersetzen (Administrator nicht vergessen).
Dieses stellt auch die Standard Vorgabe dar: „Vorhandene Berechtigungen für alle Unterschlüssel mit vererbbaren Berechtigungen ersetzen.“

Auch hier gilt, wie bei den Diensten, dass nur ein Schlüssel aus HKLM ausgewählt werden kann, der auch lokal am System vorhanden ist, da das System auf die lokale Registrierung zurückgreift. Dafür ist es in der Registry wesentlich einfacher, mal auf die Schnelle einen neuen Schlüssel zu erstellen, als einen neuen Dienst.

Der Bereich HKEY_CURRENT_USER kann nicht hinzugefügt werden da der Benutzer per Default innerhalb seiner ntuser.dat (der angemeldete und bei Anmeldung eingelesene HKEY_CURRENT_USER) Vollzugriff hat und somit eine „Erhöhung“ der Berechtigungen keinen Sinn mehr ergeben.

 

 

Dateisystem

Funktion und Vorgehensweise sollte nach den oberen Artikeln bekannt und anwendbar sein. Es gelten die gleichen Regeln. Der Pfad, der editiert wird, muss vorhanden sein, wenn nicht, dann wie gehabt: Selber erstellen

 

Als Hinweis sollte erwähnt sein, dass die Option „Vererbbare übergeordnete Berechtigungen übernehmen“ deaktiviert werden sollte, damit die neuen eigenen Berechtigungen auch propagiert werden können. Von diesen Punkt aus werden dann wieder per Default die Sicherheitsberechtigungen an die darunter liegenden Ordner vererbt, denn die Vorgabe ist: „Vererbbare Berechtigungen an alle Unterordner und Dateien übermitteln.“


 

Abschluss, in welcher Form können Berechtigungen an Systemdiensten, Registrierung und Dateisystem gesetzt werden?

·         Erben: Alle untergeordneten Objekte dieses Objekts erben die Sicherheitseinstellungen des übergeordneten Objekts, unter der Voraussetzung, dass das untergeordnete Objekt nicht vor Vererbung geschützt ist.

·         Überschreiben: In diesem Fall überschreiben die Sicherheitseinstellungen des übergeordneten Objekts alle für das untergeordnete Objekt festgelegten Sicherheitseinstellungen, unabhängig davon, ob für das untergeordnete Objekt ein Schutz eingestellt ist oder nicht.

·         Ignorieren: Verwenden Sie diese Einstellung, wenn Sie die Sicherheitseinstellungen für dieses Objekt oder die dazugehörigen untergeordneten Objekte nicht konfigurieren oder analysieren möchten.

 

 

 

 

 

Well-known SID

Beschreibung

Administratoren

(S-1-5-32-544)

Administratoren, Hauptbenutzer, Benutzer und Operatoren

Abgrenzung der unterschiedlichen Rechte, hier:

Default security settings for groups

                                                                                   

Hauptbenutzer

(S-1-5-32-547)

Sicherungs-Operatoren

(S-1-5-32-551)

Benutzer

(S-1-5-32-545)

Anonymous-Anmeldung
(S-1-5-7)

Ein Benutzer, der sich ohne Übergabe eines Benutzernamens und Passwortes mit dem System verbunden hat

Authentifizierte Benutzer
(S-1-5-11)

Beinhaltet alle Benutzer und Comuter, deren Identität authentifiziert (beglaubigt) wurde. Der GAST gehört nicht zu den Authentifizierten Benutzern auch wenn der Gast-Account über ein Passwort verfügt.

Batch
(S-1-5-3)

Beinhaltet alle Benutzer, die sich am System über eine Stapelverarbeitungs-Warteschlange wie den Geplanten Tasks am System angemeldet haben.

Ersteller-Besitzer
(S-1-3-0)

Ein Platzhalter für einen vererbbaren Access Control Eintrag (ACE), im Moment der Vererbung der ACE ersetzt das System diese SID mit der SID des aktuellen Objekt-Besitzers.

Erstellergruppe
(S-1-3-1)

Ein Platzhalter für einen vererbbaren Access Control Eintrag (ACE), im Moment der Vererbung der ACE ersetzt das System diese SID mit der SID der Primären Gruppe des aktuellen Objekt-Besitzers.

Dialup
(S-1-5-1)

Enthällt alle Benutzer, die sich mit einer Dial-Up Verbindung am System angemeldet haben.

Jeder
(S-1-1-0)

Auf Computer mit Windows Server 2003, beinhaltet JEDER die Authentifizierten Benutzer und GAST. Auf Computer mit älteren Betriebsystemen, enthält die Gruppe JEDER die Authentifizierten Benutzer und Gäste und zusätzlich die Anonymen Anmeldungen.

Weitere Inforamtionen hier: Differences in default security settings.

Interaktiv
(S-1-5-4)

Alle Benutzer, die sich lokal am System per Remote Desktop Verbindung anmelden.

System
(S-1-5-18)

Eine Dienst-Account, der vom Betriebsystem genutzt wird.

Netzwerk
(S-1-5-2)

Beinhaltet alle Benutzer, die sich über eine Netzwerkverbindung angemeldet haben. Zugriffsschlüssel (Access Tokens) für Interaktiv-Benutzer beinhalten nicht die SID von NETZWERK.

Selbst

(S-1-5-10)

Ein Platzhalter einer ACE für ein Benutzer~, Gruppen~ oder Computerobjekt im Active Directory. Wenn man Berechtigungen für SELBST setzt, so setzt man diese für das Sicherheitskonto (Security-Principal), welches dieses Objekt repräsentiert. Während einer Zugriffsüberprüfung (access check), ersetzt das Betriebsystem doe SID für das Konto “Selbst” mit der SID des Sicherheitskontos, welches das Objekt selber repräsentiert.

Service
(S-1-5-6)

Eine Gruppe die alle Sicherheitskonten (security principals) beinhaltet, die als Dienst angemeldet sind. Die Gruppenmitgliedschaft wird vom Betriebsystem kontrolliert.

TerminalserverBenutzer
(S-1-5-13)

Beinhaltet alle Benutzer, die sich am Terminal Server Dienst angemeldet haben, der im Anwendungsmodus (Version 4)  läuft.

Andere Organisation

(S-1-5-1000)

Veranlasst eine Überprüfung, ob der Benutzer eines anderen Forests oder einer anderen Domäne berechtigt ist sich für einen speziellen Dienst zu authentifizieren.

Diese Organisation

(S-1-5-15)

Wird vom Authentifizierungs Server zum Auth. Datensatz des Benutzer hinzugefügt und der Anderen Organisation übergeben.

 

 

 

 



(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright