Wer bin ich und was darf ich - Gruppenmitgliedschaften und Benutzerrechte

Hallo Ihr da im Netz :)

Wenn Ihr eine Domäne verwaltet, dann möchtet Ihr steuern, wer sich an welchen Computern anmelden darf und ob er dort dann Admin oder nur Benutzer ist. Das macht Ihr natürlich mit Gruppenrichtlinien, und Ihr verwendet dafür

• Eingeschränkte Gruppen - Legt fest, welche Domänengruppen/-benutzer Mitglied welcher lokalen Gruppen werden
• Zuweisen von Benutzerrechten - Legt fest, welche lokalen oder Domänengruppen welche Rechte bekommen (z.B. lokal oder über RDS anmelden, Zeit oder Zeitzone ändern etc.)

Im Folgenden zeige ich Euch eine Variante für diese Einstellungen, die Euch das Leben deutlich einfacher machen kann.

Die Anforderung

Für unser Beispielszenario verwenden wir einen fiktiven SQL-Server. Lokal anmelden sollen sich nur die SQL-Admins und die Server-Admins. Die SQL-Admins sollen nur normale Benutzer sein, die Server-Admins lokale Administratoren. Domänen-Admins sollen sich gar nicht anmelden können - weder lokal noch remote - das dient dem zusätzlichen Schutz vor Pass-The-Hash Attacken.

Die klassische Umsetzung

Wir erstellen eine GPO, die auf den SQL-Server wirkt. Die lokale Anmeldung erlauben wir in Computerkonfiguration - Richtlinien - Windows-Einstellungen - Sicherheitseinstellungen - Lokale Richtlinien - Zuweisen von Benutzerrechten.

 

Die Domänen-Admins lassen wir hier weg. Das verhindert allerdings noch nicht, daß Domänen-Admins sich trotzdem anmelden können – die werden nämlich den Administratoren automatisch hinzugefügt. Also konfigurieren wir auch noch Lokal anmelden verweigern und tragen hier dann die Domänen-Admins ein – den Screenshot dazu spare ich mir :-)

Damit die Server-Admins auch lokale Administratoren werden, verwenden wir Computerkonfiguration – Richtlinien – Windows-Einstellungen – Sicherheitseinstellungen – Eingeschränkte Gruppen. Hier gibt es zwei grundlegend unterschiedliche Varianten:

• Mitglieder dieser Gruppe - Legt fest, wer Mitglied der ausgewählten Gruppe ist. Alle anderen Mitglieder werden entfernt. Diese Einstellung ist also nicht kumulativ, die gewinnende GPO legt die Gruppenmitglieder fest. 
• Diese Gruppe ist Mitglied von - Fügt diese Gruppe einer anderen Gruppe hinzu. Bereits vorhandene Mitglieder bleiben dabei erhalten. Diese Einstellung ist kumulativ.

Welche davon Ihr verwendet, ist Entscheidungssache – wir verwenden immer die erste. Das sieht dann so aus:

Verknüpfe ich diese GPO jetzt mit der OU, in der sich meine SQL-Server befinden, habe ich das geforderte Ergebnis eigentlich erreicht.

Unangenehm dabei ist nur: Das ist alles sehr statisch. Kommt eine neue Serverrolle dazu, muss ich neue Gruppen und eine neue GPO erstellen. Will ich auf einzelne Server direkt noch zusätzliche Rechte vergeben, muss ich wieder neue GPOs machen.

Geht das nicht einfacher?

Das geht sogar viel einfacher, wenn wir zwei Dinge ändern:

1. Wir verwenden beim Zuweisen von Benutzerrechten keine Domänengruppen mehr, sondern lokale Gruppen (diese erstellen wir automatisch mit Group Policy Preferences).
2. Die Mitgliedschaft in Administratoren und den neuen lokalen Gruppen konfigurieren wir nicht mit Eingeschränkte Gruppen, sondern mit Group Policy Preferences Lokale Benutzer und Gruppen. Hier können wir nämlich Variablen verwenden und alle möglichen Filterungsarten.

Damit das Ganze dann wirklich einfach wird, definieren wir noch eine Umgebungsvariable %SrvRole%, in der wir die Serverfunktion speichern, hier also %SrvRole%=SQL.

Zuweisen von Benutzerrechten

Für alle Rechte, die wir individuell konfigurieren wollen, verwenden wir eine lokale Gruppe. Dieser Gruppe wird dann das entsprechende Recht erteilt bzw. verweigert.

Beim Hinzufügen verwenden wir nicht die Durchsuchen…-Schaltfläche, denn dann würde in unserer GPO nicht mehr der Gruppenname stehen, sondern die SID der Gruppe – und die ist (da lokale Gruppe) auf jedem Computer anders. Stattdessen schreiben wir den Gruppennamen einfach in das Textfeld. Administratoren müssen wir hinzufügen, da die dieses Recht zwingend benötigen.

In unserem Umfeld haben wir dabei übrigens folgende Benutzerrechte identifiziert, für die wir dieses Verfahren verwenden wollen – die Namen der Gruppen könnt Ihr natürlich frei festlegen:

Benutzerrecht	Gruppenname
Anmelden als Batchauftrag verweigern	CORP-LogonBatchDeny
Anmelden als Dienst	CORP-LogonService
Anmelden als Dienst verweigern	CORP-LogonServiceDeny
Anmelden als Stapelverarbeitungsauftrag	CORP-LogonBatch
Anmelden über Terminaldienste verweigern	CORP-LogonRDSDeny
Anmelden über Terminaldienste zulassen	CORP-LogonRDS
Auf diesen Computer vom Netzwerk aus zugreifen	CORP-NetworkAccess
Lokal anmelden verweigern	CORP-LogonLocallyDeny
Lokal anmelden zulassen	CORP-LogonLocally
Zugriff vom Netzwerk auf diesen Computer verweigern	CORP-NetworkAccessDeny

Ich verwende also eine GPO, in der ich diese 10 Benutzerrechte konfiguriere. Dabei trage ich jeweils die hier angegeben Gruppe ein. Bei manchen muss ich noch weitere Standardeinträge machen, so muss z.B. Anmelden als Dienst für LOCAL SERVICE und NETWORK SERVICE möglich sein, und manche Rechte müssen Administratoren zugewiesen werden.

Die lokalen Gruppen existieren allerdings noch nicht – macht aber nichts, das erledigen wir im zweiten Schritt gleich mit.

Lokale Benutzer und Gruppen

Mit Hilfe von Computerkonfiguration – Einstellungen – Systemsteuerungseinstellungen – Lokale Benutzer und Gruppen erstellen wir jetzt unsere lokalen Gruppen, nehmen entsprechende Domänengruppen als Mitglieder auf und konfigurieren auch die Mitgliedschaft in den lokalen Administratoren.

Lokale Gruppe erstellen

Wir erstellen %ComputerName%\CORP-LogonLocally, geben der Gruppe noch eine Beschreibung mit und entfernen alle Mitglieder. Den Computernamen setze ich hier ein, damit das auf Domain Controllern garantiert nicht funktioniert – dort würde sonst nämlich eine domänenlokale Gruppe erstellt werden.

 

Wir fügen in dieser Einstellung keine Mitglieder hinzu. Warum nicht? Wenn hier 5 Mitglieder hinzugefügt werden und eines der Mitglieder existiert nicht (oder das Hinzufügen scheitert aus anderen Gründen), dann werden alle weiteren Mitglieder nicht mehr hinzugefügt. Daher legen wir für jede Änderung der Gruppe ein eigenes Element an.

Domänen-Gruppen berechtigen

In einem zweiten Gruppenelement fügen wir CORP\Server-Admins der lokalen Gruppe hinzu.

 

Hier löschen wir natürlich keine Mitglieder mehr, das haben wir im ersten Element ja schon erledigt. Und in einem dritten Element machen wir das gleiche für die SQL-Admins. Besser gesagt: Wir machen das für CORP\%SrvRole%-Admins.

 

Dabei dürfen wir nicht die „…“-Schaltfläche verwenden, sondern wir schreiben den Gruppennamen direkt in das Textfeld. Dadurch wird die Gruppe dann auch nicht zu einer SID aufgelöst.

Eine einzige Einstellung %SrvRole%-Admins regelt jetzt also, dass sich die jeweiligen Administratoren auf den jeweiligen Servern anmelden können.

Administratoren konfigurieren

Jetzt müssen wir noch die Mitgliedschaft in den lokalen Administratoren konfigurieren. Die Vorgehensweise ist dabei grundsätzlich gleich:

Erstes Element: Alle vorhandenen Mitglieder löschen

Weitere Elemente: Einzelne Domänengruppen hinzufügen – auch wieder nur eine Gruppe pro Element wegen Abbruch bei Fehler

In der Gesamtübersicht sieht das dann so aus:

1. CORP-LogonLocally erstellen/aktualisieren, alle Mitglieder entfernen 
2. CORP\Server-Admins in CORP-LogonLocally aufnehmen 
3. CORP\%SrvRole%-Admins in CORP-LogonLocally aufnehmen 
4. Administratoren aktualisieren, alle Mitglieder löschen 
5. CORP\Server-Admins in lokale Administratoren aufnehmen 
6. CORP\%Computername%-Admins in lokale Administratoren aufnehmen

Der letzte Schritt ermöglicht mir dabei die individuelle Konfiguration der lokalen Admins über eine Domänengruppe. Existiert diese, dann wird sie lokaler Administrator. Existiert sie nicht, dann gibt’s einen Fehlereintrag im Log, aber der Rest funktioniert trotzdem. Und wenn mich der Fehlereintrag stört: Zielgruppenadressierung verwenden :-)

In der Praxis sind hier natürlich noch mehr Einträge für die restlichen Benutzerrechte vorhanden, aber das Prinzip ist verdeutlicht.

BTW: Wer sich fragt, wie ich die Einträge in der Spalte Name geändert habe – einfach F2 drücken.

Die Kür

Die bisherigen Schritte waren die Pflicht – jetzt reicht uns also eine einzige GPO, um Benutzerrechte und Gruppenmitgliedschaften für alle unsere Server zu konfigurieren. Aber für Arbeitsplätze lässt sich das natürlich auch verwenden – auch hier erstelle ich eine lokale Gruppe CORP-LogonLocally. Und mit Hilfe von ein wenig Zielgruppenadressierung lege ich dann fest, dass die Server-Admins und Rollen-Admins nur auf Servern hinzugefügt werden – auf Clients dagegen die Domänen-Benutzer.

Wenn Euch %SrvRole% nicht reicht, dann verwendet einfach mehr Variablen. Verbindet das ggf. noch mit einer Zielgruppenadressierung, ob die jeweilige Variable auch existiert, das unterdrückt dann sogar die Fehlermeldungen.

Die Schleifchen

Was mich jetzt noch stört:

• Der Server-Admin kann auf den Server auch remote zugreifen. Damit landet sein Passwort-Hash aber im Hauptspeicher des verwendeten Clients – und das will ich nicht. Also werden auf Clients die Server-Admins in CORP-LogonLocallyDeny aufgenommen – das geht per Zielgruppenadressierung auf Win32_OperatingSystem.ProductType=1.
• Die Server-Admins können auf alle Server auch remote zugreifen. Wenn ich das nicht will, muss ich ein wenig umbauen. Ich verwende dann nicht die Computerkonfiguration, sondern die Benutzerkonfiguration. Und ich nehme nicht die Domänengruppe in die Administratoren auf, sondern direkt den Benutzer – und zwar mit einer Zielgruppenadressierung auf Benutzer ist Mitglied von Sicherheitsgruppe CORP\Server-Admins.

Fragen? Fragen!

Ansonsten: Viel Spaß beim Umsetzen!

PS: Mir ist bewusst, dass die Liste der Gruppeneinträge lang werden kann (20 bis 60 Elemente). Aber ein wenig Planung und Dokumentation im Vorfeld und dann nie wieder anfassen – das ist es wert, oder?