Wednesday, April 01, 2015

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?

3 comments:

  1. Hallo Martin,

    ich finde den Ansatz dieses Artikels sehr interessant und wollte das Ganze vor einem produktiven Einsatz erstmal in einem LAB austesten.

    Irgendwie stoße ich da allerdings beim Anlegen der lokalen Gruppen auf den jeweiligen Servern auf eine unschöne Fehlermeldung im EventLog, bei der ich nicht wirklich weiter komme und hoffe hier eine Antwort auf dieses Problem zu finden ;)

    Du legst die lokalen Gruppen explizit unter Angabe der %ComputerName%-Umgebungsvariable nach dem Muster %ComputerName%\CORP-LogonLocally an und begründest dies mit der Tatsache, dass so auf DCs (sofern ihnen die GPO zugewiesen wird) keine domänenlokale Gruppen erzeugt werden.

    Und genau dabei kommt es bei mir zum Fehler:

    Das Computer "LAB-LogonLocally erstellen"-Einrichtungselement im Gruppenrichtlinienobjekt "Server Security" wurde aufgrund eines Fehlers nicht angewendet. Fehlercode "0x8007089a Der angegebene Benutzername ist unzulässig"

    Ich verwende hier folgende Syntax innerhalb der GPP %ComputerName%\LogonLocally

    Entferne ich die UV %ComputerName% und belasse einfach LogonLocally wird die Gruppe ordnungsgemäß auf den Servern angelegt...

    Zwar könnte ich dafür sorgen, dass die GPO definitiv nicht auf DCs angewendet wird, finde aber Deinen Ansatz deutlich eleganter...

    Any Idea?

    Vorab ganz herzlichen Dank!

    Gruß Erich

    ReplyDelete
    Replies
    1. Hallo Erich.
      Kommt der Fehler auf DCs oder auf Member Servern? Davon unabhängig: Ich lasse das %Computername%\ inzwischen weg, das klappt. Und als Gruppenname verwende ich einfach den Namen des zugehörigen Rechts, hier also seInteractiveLogonPrivilege.
      In unserer aktuellen Umgebung mache ich das für ALLE Benutzerrechte (47 Stück), und das funktioniert prima.
      Du kannst mir auch gerne mal ne Mail dazu schreiben, wenn ich helfen kann:
      martin
      unterstrich
      binder
      at
      outlook
      punkt
      de
      :-))

      Delete
    2. Hi Martin,

      erst einmal ganz herzlichen Dank für die schnelle Rückantwort.
      Die Fehlermeldung erscheint auf den Memberservern auf denen die neuen Gruppen erzeugt werden sollen...

      Ich hab das in meinem LAB jetzt auch ohne die UV %ComputerName% belassen und verhindere zusätzlich noch über die Zielgruppenadressierung, dass DCs das Ding ziehen.

      Dein Angebot, Dich per Mail zu kontaktieren, werde ich mit 100%iger Sicherheit in Anspruch nehmen und möchte mich vorab dafür sehr herzlich bedanken. Insbesondere interessiert mich, wie du die GPO per Zielgruppenadressierung für Server und Client unterscheidest um bspw. zu verhindern, dass sich %ComputerName%-Admins bzw. %SrvRole%-Admins nicht an Clients anmelden dürfen. ;)

      Also ich komme definitiv auf dein Angebot zurück!!!

      VG

      Delete