MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Anwender als lokaler Admin?

Einige Aktionen auf einem Windows Client können Sie nur mit privilegierten Berechtigungen ausführen. Das ist gut so aber möchten Sie sich das Leben als Administrator etwas einfacher machen oder haben sie einen nervenden Anwender, der immer wieder Admin-Rechte einfordert? Das wäre der leichte Weg aber was ist eigentlich falsch daran?

"Mach mich Admin!"

Jedes moderne Betriebssystem kennt unterschiedliche Benutzer und Berechtigungskonzepte. Microsoft hat dies mit Windows NT 3.1 im Sommer 1993 eingeführt. Für Unix war das zu der Zeit schon lange möglich. Ziel war, dass ein normaler Anwender maximal in seinem Prozessbereich mit seinen Rechten etwas tun aber nie das eigentliche Betriebssystem oder andere Benutzer beschädigen konnte. Änderungen an Systemeinstellungen, Installation von Treibern und Software und andere privilegierte Tätigkeiten konnte nur ein Administrator durchführen.

Das funktioniert in einem "verwalteten Netzwerk" solange gut, wie die IT-Abteilung auch die gewünschte Leistung erbringen kann. Oft dauert es aber Anwendern zu lange und gerade in der Anfangszeit von Windows NT waren auch viele Programme noch gar nicht darauf eingestellt, dass der Anwender nur eingeschränkte Berechtigungen hatte und z.B. gar keine Updates einspielen konnte und auch in C:\Programme\Programmverzeichnis z.B. keine Dateien schreiben sollte. Heute ist das Problem deutlich reduziert und "moderne Apps", die im Grunde mur Webseiten im Userspace sind ,funktionieren direkt im Browser oder legen sich gleich im Benutzerbereich ab, was auch nicht ohne Risiken sind.

Dennoch gibt es Anwender, die gerne lokaler Administrator sein wollen, z.B. Entwickler, die häufig Updates installieren oder Dienst starten, die einen Ports öffnen, was durch die Windows Firewall gerne und zurecht blockiert wird. Mit genug Quengeln lässt sich dann doch eine IT breitschlagen und gewährt dem Anwender auf die ein oder andere Weise die höheren Privilegien, z.B.

  • Anmeldekonto wird "lokaler Admin"
    Sie addieren das Anmeldekonto in die lokale Administratoren-Gruppe, was den Anwender damit zum lokalen Administrator macht. Damit die höheren Privilegien nicht immer und überall aktiv sind, gibt es natürlich "User Account Contol", so dass der Anwender noch mal explizit zustimmen muss. Ein Zugeständnis und durchaus eine Verbesserung der Sicherheit, wenn der Anwender denn damit umzugehen weis.
  • Eigenes Admin Konto (Lokal oder Domain)
    Die zweite Option ist ein separates Anmeldekonto für administrative Tätigkeiten auf dem Computer vielleicht sogar weiteren Systemen in Netzwerk. Das ist dann eine recht klare Trennung, die aber viele Anwender als zu kompliziert bezeichnen.

Wir gehen in der Folge davon aus, dass ein Anwender zumindest auf seinem lokalen Computer zeitweise oder auf Anforderung sich mit lokalen Administrator-Berechtigungen bewegen kann.

Der PC ist nicht mehr "managed"

Aus meiner Sicht ist dieser PC dann nicht mehr "exklusiv durch die IT verwaltet". Natürlich können Sie als zentrale Instanz mit ihren Privilegien und MDM-Lösungen das Gerät weiterhin inventarisieren und auch wichtige und kritische Updates erzwingen. Es bleibt aber ein Gerät, welches auch vom mindestens einem Anwender "Co-Administriert" wird.

Es ist eigentlich nicht möglich, alle Änderungen durch diese Co-Administration zu erkennen und zu protokollieren. Gehen sie nicht davon aus, dass der Anwender sie über alle Änderungen informiert.

Aus meiner Erfahrung sind solche Systeme deutlich supportintensiver als voll verwaltete Systeme. Es wird immer wieder Probleme oder Fragestellungen geben, die der Anwender aufgrund seiner Berechtigungen vielleicht selbst hätte lösen können aber der fachliche Hintergrund gefehlt hat.

Wie werden als auch auf diesen Systemen als PC-Admin, Helpdesk-Admin oder schlimmstenfalls und leichtsinnig als Domain Admin helfen.

Risiko!

Es geht dabei nicht um die Eskalation durch den Anwender, der ein Problem möglichst schnell und mit entsprechendem Nachdruck gelöst haben will. Das ist eine legitime Forderung aber ich komme immer mehr zur Überzeugung, dass ich mich als IT-Dienstleister auf diesem Computer überhaupt nicht mehr anmelden möchte. Ich weiß ja gar nicht, welche Überraschungen auf dem System auf mich warten.

Der Anwender kann mit seinen Berechtigungen ja auch diverse andere Programme und Tools installiert haben. Vielleicht hat er auch das ein oder andere PowerShell-Modul installiert. Es reicht, wenn er eine Software oder Modul installiert hat, welches nur darauf wartet bis ein ein wertvoller Fisch vorbekommt. Und das ist z.B.

  • Ein anderes privilegiertes Admin-Konto
    d.h. ein Helpdesk-Mitarbeiter, der sich mit einem entsprechenden Konto auf den Client aufschaltet oder per Fernsteuerung dem Mitarbeiter helfen will.
  • Ein MDM-Prozess mit Konto
    Vielleicht ist der Fisch schon lange vorhanden, z.B. in Form einer Client Management Lösung, einer Überwachungslösung o.ä., die nicht als "LocalSystem" oder "NetworkSystem" läuft, sondern mit einem schlecht gesicherten Dienstkonto. Es ist eher der Regelfall, dass solche Dienste auf allen Computer mit dem gleichen Konto laufen.
  • Eine Monitoring-Lösung remote zugreift
    Viele Überwachungsprogramme wie z.B. PRTG nutzen ein privilegiertes Dienstkonto, um aus der Ferne Eventlogs auszulesen, Performance Counter anzufragen oder den Start von Diensten zu prüfen.
    Das passiert aber meist nur auf Servern und weniger auf Clients. Ist aber ebenfalls zu beachten, wenn Anwender z.B. auf einzelnen Servern gewisse administrative Tätigkeiten macht. Ich hoffe für sie, dass kein Anwender "lokaler Admin" auf einem Terminal Server ist.

Das reale Risiko ist hier, dass der Anwender unabsichtlich oder auch absichtlich mit seinen Admin-Rechten auf dem Client eine Komponente installiert, die weiter als "local Admin" oder "LocalSystem" aktiv bleibt. und das ist nicht nur ein theoretisches Risiko.

Eskalation

Aus einem realen Vorfall bei einem Kunden lässt sich wohl am besten Erläutern, warum Sie auf der Hut sein sollten, an welchem System sich ein privilegierter Benutzer anmeldet und welchen Vertrauenslevel solche Systeme haben. Ich bin ein Freund von PAW – Priviledged Admin Workstation.

  1. Malware landet auf dem Client
    In diesem Fall war ein PlugIn für eine bekannte Video-Schnitt-Software, welches ganz neue KI-gestützte Bearbeitungen erlauben sollte. Aber es kann eigentlich auch ein Makro, eine "Free"-Ware oder ein Treiber oder ein Tool in der Tray-Leiste o.ä. sein, der auf die richtige Gelegenheit warten.
    Schon jetzt könnte dieser Code "wie der Anwender" viele Dinge tun, z.B. Dateien und Mails lesen und über den Internet-Zugriff auch ausleiten. Das kann schon interessant sein aber fällt vielleicht auch auf. Mein Ziel ist ja "Admin" werden. Als Malware wäre auch ein Programm in "All Users - Autostart" eine Option, um sich dann mit einer "Update-Meldung" Berechtigungen zu beschaffen.
  2. Benutzer nutzt seine Admin-Rechte
    Irgendwann wird der Anwender  ja die ihm gewährten Rechte auch ausüben, z.B. weil er ein Update oder Treiber installiert oder das alte Programm einfach nicht ohne Admin-Rechte arbeitet. Wenn der Anwender z.B. ein Video bearbeitet, dann könnt das PlugIn vorgeben, dass es Admin-Rechte braucht, um auf einen lokalen KI-Chip oder die Beschleunigungsfunktionen der Grafikkarte zuzugreifen. Schnell ist immer besser und so nickt der Anwender diese Bitte ab.
  3. Credential Sammlung und Discover
    Mit den privilegierten Rechten kann die Software nun aber auch hingehen, und den Computer nach gespeicherten Zugangsdaten durchsuchen. Das könnten Daten in einem Browser-Cache, dem RDP-Cache, Registry oder den vielen Programmen wie Outlook etc. sein, die ihre Kennworte mehr oder minder gut gesichert speichern. (Siehe z.B. Password Recovery Utilities https://www.nirsoft.net/utils/index.html#password_utils). Manchmal reichen auch Hashwerte aus dem Hauptspeicher oder Kerberos-Tickets.
    Denken Sie z.B. an einen Dienst, welcher aktuell mit einem Domain User gestartet ist, der auf allen anderen PCs auch läuft und die Malware kann sich dessen Zugangsdaten oder Rechte aneignen.
  4. Discovery
    Mit all den mittlerweile auf dem lokalen Computer erhaltenen Zugangsdaten kann sich die Malware durch ihr Netzwerk bewegen um mehr über Schwachstellen zu erfahren.
  5. Laternal Movement
    Meist ist mehr als ein weiteres mit diesen Zugangsdaten erreichbar und die Malware kann dort ebenfalls einen Prozess installieren und z.B.: per Taskplaner starten lassen. Eventuell gibt es auf dem Computer sogar schon Tasks, die mit einem  GMSA - Group Managed Service Account laufen und sich der neue Dienst auch dieses Konto nutzt.
  6. Jetzt fehlt nur noch, dass die Malware z.B. Kennworte eines Admin zurücksetzen kann oder gleich mit den Zugangsdaten eines Admins weitere Aktionen auslöst, z.B. auch sich ins EntraID ausweitet.

Das alles war aber nur möglich, weil ein Benutzer auf seinem Desktop lokale Admin-Rechte hatte und Code dort hinterlassen hat, welcher auf einen Admin, sei des der Benutzer, ein IT-Servicemitarbeiter oder ein Dienst gewartet hat.

Was ein Admin noch kann

Es geht aber noch weiter, denn auch der legitime Benutzer mit seinen Admin-Rechten kann ziemlich viel Unfug anstellen, wenn es auf dem Computer weiter Anwender oder Dienste gibt. Hier ein paar Beispiele:

  • Bitlocker ist kein Schutz für Benutzrerprofile
    Die Festplattenverschlüsselung sichert die Daten der Festplatte gegen Zugriffe ohne den passenden Key. Da aber das normale Windows gestartet ist, kann der Admin-User problemlos sich Zugriff auf alle Verzeichnisse verschaffen. Das können auch die Profilverzeichnisse von anderen Anwendern auf diesem Computer sein, was weitere Rechteerweiterungen erlaubt.
    Er kommt also auch an "HKEY_CURRENT_USER" und LocalAppData des anderen Anwenders ran und damit dort hinterlegte Cookies, Zugangsdaten, RDP Credential Store etc.
  • Computer-Zertifikate
    Als Admin kann ich nicht nur meine Benutzer-Zertifikate lesen und nutzen, sondern auch Computer-Zertifikate erreichen. Es ist kein Geheimnis, dass man als Administrator und den passenden Tools auch Zertifikate samt privatem Schlüssel exportieren kann. Wenn Sie den Zugang zu ihrem Netzwerk nun mittels 802.1x - Zugang zum Netzwerk absichern, dann kann ein Admin das dazu genutzte Zertifikat sehr einfach auf einen anderen Computer übertragen.
  • Taskplaner und Dienste
    Er kann nicht nur schauen, welche weitere "Dienste" oder "Geplante Tasks" auf dem Computer mit privilegierten Rechten laufen, sondern den Code entsprechend austauschen. Das ist besonders kritisch, wenn solche Programme mit einem privilegierten Domainkonto ausgeführt werden.
  • Prozess-Zugriff
    Mit den passenden Werkzeugen kann ein Admin sich an einen laufenden Prozess anhängen und die Daten extrahieren. Denken Sie an einen Administrator, der per RemoteCommand, Remote PowerShell o.ä. auf einen so kompromittierten Server aktiv ist und das Kerberos TGT damit in falsche Hände fällt

Vielleicht wird nun klar, warum so ein Client nicht mehr als vertrauenswürdig gelten darf.

Raus aus der Domain?

Zu viel lokale Berechtigungen sind nicht nur für den Benutzer sondern auch den Client und damit das Netzwerk und die Firma ein hohes Risiko. Sicher gibt es "IT-Consultants", "Entwickler" und andere Personen, die ganz ohne lokale Administrationsrechte nicht sinnvoll arbeiten können. Dann müssen Sie sich aber zweimal überlegen, welchen Status sie so einem Client geben wollen.

  • Darf er dann noch ein "Domainmitglied" sein?
    Oder ist er besser ein Standalone-Computer, nur Entra ID-Joined oder in einem anderen Forest Mitglied, der dann ihrem primären Forest traut?
    Diese Frage ist nicht nur theoretisch, sondern real zu betrachten, wenn Sie ihr "verwaltetes Netzwerk" besser sichern müssen
  • Dürfen Sie sich dort als Admin anmelden?
    Ich würde mich auf so einem unsicheren Computer nicht mehr anmelden. Ein einfacher "Keylogger" könnte schon mein Kennwort mitschneiden und Kerberos-Tickets und SAML-Tokens abgreifen.
  • System/Profil-Reset
    Haben Sie sich mal überlegt, einen Client als Azure VM oder Windows 365 zu betreiben und nach der Abmeldung des Benutzers wieder auf einen definierten Ausgangspunkt zu bringen?

Sie wissen ja nie, wie ein anderer Benutzer vor ihnen das System hinterlassen hat.

Mein Entwurf

Vielleicht reicht es für den Anfang, einige Grundregeln zwischen einer Anmeldung "auf" einem Computer im vergleich zur Anmeldung "an" einen Dienst vorzunehmen.

Hinweis: Eine Anmeldung per RDP oder eine Remote Shell oder einen Dienst zähle ich als "drauf anmelden". Eine Fernunterstützung per RemoteHelp, Teamviewer, VNC o.ä. ist eine Aktion "mit dem Benutzer" und keine Anmeldung durch einen Admin.

  • Domaincontroller
    Ich würde die Anmeldung AUF dem Server extrem minimieren, denn fast alle Aktionen mit einem Domain Controller können sich von einer PAW – Priviledged Admin Workstation ausführen. Über die MMC für Benutzer und Computer können sie mit klar delegierten Berechtigungen arbeiten, so dass gar kein Zugriff auf IPC$ oder C$ erforderlich ist. Nur Domain Administrator sollten sie auf dem Server direkt anmelden, wen es wirklich nicht anders geht
  • Member Server
    Hier haben auch nur die Administratoren etwas "drauf" verloren, wenn eine Verwaltung aus der Ferne per MMC o.ä. nicht möglich ist
  • "Standard Workstations"
    Wenn sie die Hoheit über "Local Admin" nicht abgegeben haben, dann ist das System als "managed Client" vermutlich sicher.
  • Workstation mit Anwender-Admin
    Das System ist nicht vertrauenswürdig und ich würde jede Anmeldung drauf oder dran vermeiden wollen. Wenn der Anwender Hilfe braucht, dann hat er ja ein Admin Konto, welches Sie im Rahmen einer Fernsteuerung nutzen können. Da brauchen Sie nicht ihren eigenen Admin ins Risiko zu setzen.

All die Risiken mit lokalen Clients haben Sie natürlich nicht, wenn Anwender einfach nur Anwender sind und keine lokalen Admin-Rechte oder andere Privilegien bekommen.

Weitere Links