Zentrale Steuerung und Vergabe von lokalen Sicherheitseinstellungen der Clients über die Optionen:
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.
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)
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.
|
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 |
Ein Benutzer, der sich ohne Übergabe eines Benutzernamens und Passwortes mit dem System verbunden hat |
|
Authentifizierte
Benutzer |
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 |
Beinhaltet alle Benutzer, die sich am System über eine Stapelverarbeitungs-Warteschlange wie den Geplanten Tasks am System angemeldet haben. |
|
Ersteller-Besitzer |
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 |
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 |
Enthällt alle Benutzer, die sich mit einer Dial-Up Verbindung am System angemeldet haben. |
|
Jeder |
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 |
Alle Benutzer, die sich lokal am System per Remote Desktop Verbindung anmelden. |
|
System |
Eine Dienst-Account, der vom Betriebsystem genutzt wird. |
|
Netzwerk |
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 |
Eine Gruppe die alle Sicherheitskonten (security principals) beinhaltet, die als Dienst angemeldet sind. Die Gruppenmitgliedschaft wird vom Betriebsystem kontrolliert. |
|
TerminalserverBenutzer |
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. |