Einfache Maßnahmen für mehr Sicherheit im AD (Teil 4): Lokale Administratoren

Im dritten Teil der Artikelserie “Einfache Maßnahmen für mehr Sicherheit im AD” hatte ich LAPS für Server und Clients behandelt. Zugegeben: Der LAPS Artikel ist nun schon etwas länger her, das Thema ist aber nicht vergessen. Daher gibt es jetzt einen neuen Artikel bezüglich “Einfache Maßnahmen für mehr Sicherheit im AD”. In diesem vierten Teil geht es nun um die lokalen Administratoren auf AD-Computern.

Zunächst einmal zum Hintergrund: Das Thema “lokale Admins” hat scheinbar wieder etwas Fahrt aufgenommen und viele Unternehmen sind auf LAPS und Admin Tiers aufmerksam geworden und haben es vielleicht (hoffentlich) sogar schon implementiert.

In nahezu jeder Umgebung braucht aber auch hin und wieder mal ein Anwender lokale Administrator Berechtigungen, denn selbst für die Installation eines Druckers sind Admin-Rechte nötig. Benutzer brauchen die Admin-Rechte allerdings normalerweise nicht dauerhaft. sondern nur für einen begrenzten Zeitraum, beispielsweise für die Installation eines neuen Druckers. Wenn bereits LAPS umgesetzt wurde, könnte man dem Benutzer jetzt Zugriff auf LAPS geben, damit der Benutzer das Passwort für das lokale Administrator Passwort anfordern und für bestimmte Aktionen verwenden kann. In diesem Fall könnte der Benutzer allerdings immer wieder das lokale Administrator Passwort anfordern und für beliebige Aktionen verwenden und auch sein eigenes Benutzerkonto zur Gruppe der lokalen Administratoren hinzufügen. Dem Benutzer Zugriff auf LAPS zu geben, birgt also ein gewisses Risiko.

Es gibt aber eine mögliche Lösung für dieses Problem: Man kann Benutzerkonten nur temporär Admin-Zugriffe erlauben. Ein Benutzer erhält somit nur zeitlich begrenzt Admin-Rechte, kann beispielsweise einen neuen Drucker installieren und verliert nach Ablauf einer Frist wieder die Admin Rechte.

In diesem Artikel geht es nun darum Benutzern nur temporäre Admin-Rechte zu gewähren und die lokale Gruppe “Administratoren” auf den Clients “sauber” zu halten. Die Voraussetzung dafür sind einfach umzusetzen, im Prinzip kümmert sich das AD selbst um die zeitlich begrenzte Gruppen Mitgliedschaft, nur beim Hinzufügen eines Benutzers muss man etwas aufpassen.

Voraussetzungen für temporäre Administratoren

Damit Benutzerkonten temporär zu Gruppen hinzugefügt werden können, muss das Gesamtstruktur- und Domänenfunktionslevel “Windows Server 2016” entsprechen:

Alle Domain Controller innerhalb der Gesamtstruktur müssen also mindestens Windows Server 2016 als Betriebssystem nutzen.

Zusätzlich muss das „Privileged Access Management Feature“ aktiviert werden, dies kann mit folgendem Befehl durchgeführt werden:

Bei Gesamtstrukturen, welche direkt mit Windows Server 2016 installiert wurden, ist der oben genannte Befehl nicht erforderlich, das „Privileged Access Management Feature“ ist dort bereits aktiviert.

Das sind auch schon alle Voraussetzungen.

Administratoren Gruppen für Computer erzeugen

Damit administrative Berechtigungen via AD-Gruppen gesteuert werden können, benötigt jeder Computer seine eigene Gruppe im Active Directory. Zu jedem Computer wird daher eine neue Gruppe erzeugt, so wie hier in diesem Beispiel zu sehen:

Hier bietet es sich an, den Computernamen der Gruppe voran zu stellen, damit man so schnell die Gruppen im AD findet, zu denen man später die Benutzerkonten hinzufügen will. Ebenfalls ist es sinnvoll die Gruppen für lokale Admin-Rechte in einer separaten OU zu speichern, auch dies Erleichtert das Wiederfinden und die Automatisierung. Mittels der AD-Suchfunktion findet man so schnell die entsprechende Gruppe zum Computer.

Normalerweise hat man aber keine Lust für jeden Computer manuell die entsprechende Gruppe anzulegen, außerdem muss man ja auch daran denken, eine entsprechende Gruppe wieder zu löschen, wenn der Computer aus dem AD entfernt wird. Ohne ein bisschen Automatisierung endet dies also schnell im Chaos.

Ich hab dazu auch mal ein kleines PowerShell Script vorbereitet, welches per Task Scheduler zyklisch ausgeführt werden kann. Im Script müssen nur die ersten 2 Zeilen angepasst werden:

• $ComputerOU = DN zur OU wo sich die Computer Konten befinden
• $GroupOU = DN zur OU wo die Gruppen erstellt werden sollen
• $GroupSuffix = Suffix, welcher an den Gruppennamen angehangen wird (optional)

Das Script erstellt zu jedem Computer Account innerhalt der angegebenen OU eine entsprechende Gruppe (CL1_LocalAdmins, wie im Beispiel). Wird ein Computer nicht mehr im AD gefunden, wird auch die entsprechende Gruppe wieder gelöscht. Das Script kann beispielsweise täglich (oder auch häufiger) per Task Scheduler ausgeführt werden. Hier kann das Script runtergeladen werden:

GPO für das Hinzufügen der Admin Gruppen zu lokalen Administrator Gruppe

Manuell will nun aber niemand die erzeugten Active Directory Gruppen zur lokalen Administrator Gruppe der Clients und Server hinzufügen. Dies kann daher ebenfalls per Gruppenrichtlinie automatisiert werden. Sobald die Admin Gruppen für die Computer im AD erzeugt wurden (bzw. durch das Script erzeugt werden), kann eine GPO erstellt werden, welche die jeweilige AD Gruppe zur lokalen Admin Gruppe des Clients hinzufügt.

Um es etwas deutlicher zu machen: In meinem Lab habe ich 3 Clients (PC1, PC2 und PC3), das oben verlinkte Script hat für jeden Computer eine Gruppe im AD erzeugt (PC1_LocalAdmins, PC2_LocalAdmins und PC3_LocalAdmins):

Die Gruppe “PC1_LocalAdmins” soll nun per Gruppenrichtlinie auf dem PC1 zur lokalen Gruppe “Administratoren” hinzugefügt werden. Hier wird jetzt nicht für jeden Client eine Gruppenrichtlinie benötigt, sondern nur eine GPO für alle Clients. Es ist daher egal, ob sich 3, 50, oder tausende Clients im AD befinden, eine GPO reicht aus.

Es wird daher eine neue leere Gruppenrichtlinie erstellt und die “Benutzerkonfigurationseinstellungen deaktiviert”:

Unter der Einstellung “Lokale Benutzer und Gruppen” kann nun ein neuer Eintrag für eine lokale Gruppe hinzugefügt werden:

Als Aktion wird “Aktualisieren” gewählt und als Gruppenname “Administratoren (integriert)” ausgewählt. Die beiden Häkchen “Alle Mitgliederbenutzer löschen” und “Alle Mitgliedergruppen löschen” halten die lokale Administrator Gruppe sauber und entfernen alle bereits bestehenden Berechtigungen (siehe Hinweis am Ende des Abschnitts). Als Mitglieder können nun zunächst die “Domain Admins” hinzugefügt werden, so hat man noch einen Fuß in der Tür (Aufgrund der Beschränkungen der Admin Tiers dürfen sich Domain Admins ja nicht an Clients anmelden, eine entsprechende GPO sollte dies verhindern):

Damit nun auch die erstellen Admin Gruppen aus dem AD zur lokalen Gruppe hinzugefügt werden, kann ein weiteres Gruppenmitglied mit Angabe einer Variable hinzugefügt werden. In diesem Fall setzt sich der Gruppenname aus dem Namen des Computers und dem Suffix “_LocalAdmins” zusammen. Für den Computernamen gibt es die Variable “%ComputerName%”. Der Eintrag für das lokale Gruppenmitglied ist in meinem Lab also:

• FRANKYSWEBLAB\%ComputerName%_LocalAdmins

In den Eigenschaften der lokalen Gruppe “Administratoren” finden sich jetzt also zwei Mitglieder:

Die neue Gruppenrichtlinie muss nun noch mit den entsprechenden OUs verknüpft werden:

Nachdem die Richtlinie auf einem Client angewendet wurde, sieht es in der lokalen Gruppe “Administratoren” nun wie folgt aus (der Client im Beispiel heißt hier CL1, daher auch der der Name der AD Gruppe CL1_LocalAdmins“):

Jetzt kann man bereits kann bequem über die entsprechenden Gruppen im AD die lokalen Admin Berechtigungen verwalten. Benutzer welche Admin Berechtigungen erhalten sollen, müssen also nicht mehr lokal in die Administrator Gruppe aufgenommen werden, sondern werden einfach in entsprechenden AD-Gruppe aufgenommen. Ganz nebenbei löst man damit auch das Problem mit verwaisten SIDs in lokalen Gruppen. In diesem Fall wären die Benutzer den Gruppen allerdings statisch zugeordnet, temporäre Mitgliedschaften funktionieren etwas anders, dies ist im nächsten Abschnitt beschrieben.

Hinweis: Die Häkchen bei “Alle Mitgliederbenutzer löschen” und “Alle Mitgliedergruppen löschen” können auf Clients meist recht schmerzlos gesetzt werden, hier beschweren sich dann ggf. Benutzer, dass keine Software mehr installiert werden kann: Gut so, das ist ja ein Ziel von diesem Konzept. Auf Servern muss man hier schon etwas vorsichtiger vorgehen, in der lokalen Admin Gruppe befinden sich oft Service Accounts welche für die Funktion von Diensten benötigt wird (Beispielsweise Exchange Server). Für Server könnte man also die beiden Häkchen weglassen und die Gruppen manuell oder per Script bereinigen, per PowerShell ist dies relativ einfach möglich. Per WMI und PowerShell könnte man zunächst die Mitglieder der lokalen Admin Gruppe auslesen und diese dann der AD Gruppe hinzufügen, erst danach wird dann die GPO aktiviert. Gleiches gilt natürlich auch für Clients. Ich hätte da ein Script zur Hand, dies müsste allerdings stark an die eigene Umgebung angepasst werden, sodass ich es hier nicht allgemein veröffentlichen werde. Bei Interesse einfach eine Mail schreiben, dann stelle ich es gern zur Verfügung, aber wie bereits gesagt, da muss noch Hand angelegt werden.

Temporäre Admin Berechtigungen

Die Vorbereitungen für temporäre Admin Berechtigungen sind nun soweit abgeschlossen. Es gibt allerdings eine kleine Hürde, welche das Zuweisen temporären Admin Berechtigungen etwas kompliziert macht: Das temporäre Zuweisen eines Benutzers zu einer Gruppe funktioniert nur via PowerShell (wenn man nicht gleich einen Identity Manager einsetzen will).

Das temporäre Zuweisen eines Benutzers zu einer Gruppe funktioniert via PowerShell mit den folgenden Befehlen:

Mit dem oben genannten Befehl kann ein Benutzer für 60 Minuten zu einer Gruppe hinzugefügt werden. Nach Ablauf der 60 Minuten wird das Konto wieder automatisch aus der Gruppe entfernt.

Alternativ kann man sich mit der PowerShell auch eine kleine GUI basteln, welche einem die Arbeit abnimmt, hier mal als Beispiel:

Auch dieses kleine Script kann hier runtergeladen werden:

Ich habe das Script mit PowerShell Studio erstellt, die entsprechende Projektdatei liegt dem Download bei. Wer möchte kann also das Script nach seinen eigenen Anforderungen anpassen. Das Script erfordert das Active Directory Modul für die Powershell und die DLL “CubicOrange.Windows.Forms.ActiveDirectory.dll”, welche den Auswahldialog des ADs zur Verfügung stellt. Die DLL liegt dem Archiv ebenfalls bei.

Tipp: Wenn Benutzer temporär Admin Rechte auf einem Client halten sollen, dann bietet es sich an, einen separaten Benutzer zu verwenden. Beispiel: Wenn Anwender “Frank” mit dem Benutzernamen “Frank” an seinem PC angemeldet ist, dann erhält nicht der Benutzer “Frank” lokale Admin Rechte, sondern ein separater Benutzer “Frank_Admin” die temporäre Admin Berechtigung. Der Benutzer “Frank_Admin” wird also anstelle des Benutzers “Frank” zur Admin Gruppe des Computers hinzugefügt. Der Benutzer “Frank” muss sich also nicht von seinem PC abmelden, sondern kann den Benutzer “Frank_Admin” verwenden, wenn die Aufforderung von Windows erscheint, dass administrative Rechte benötigt werden.