Lokale Admin-Rechte entziehen, ohne Chaos zu stiften

Lokale Administratorrechte sind der stille Wegbereiter der meisten Kompromittierungen von Arbeitsplätzen. Eine Phishing-Payload, die als Standardbenutzer läuft, ist eingedämmt: Sie kann keinen Treiber installieren, Defender nicht abschalten, den LSASS-Speicher nicht lesen und keinen Dienst einrichten. Dieselbe Payload in einer Admin-Sitzung kann all das, und tut es meist innerhalb von Minuten. Microsofts eigene Auswertungen zu Schutzmaßnahmen zeigen seit Langem, dass ein großer Teil der kritischen Schwachstellen ohne Administratorrechte deutlich schwerer auszunutzen ist.

Die Säule Konten & privilegierter Zugriff behandelt die architektonische Seite: Admin-Tiering und eindeutige lokale Kennwörter mit LAPS. Dieser Leitfaden beschreibt das praktische Projekt dazwischen: Alltagsbenutzer aus der lokalen Gruppe Administrators herauszubekommen und draußen zu halten, ohne den Helpdesk zu überfluten.

Schritt 1: Erheben, wer heute Admin ist

Was Sie nicht gemessen haben, können Sie nicht entfernen. Lokale Gruppenmitgliedschaften verändern sich schleichend durch alte Imaging-Skripte, Helpdesk-Abkürzungen („ich füge Sie mal eben hinzu“), Installationsprogramme von Herstellern und die Standardwerte beim Microsoft-Entra-Join. Erfassen Sie sie auf jedem Gerät, bevor Sie irgendetwas ändern.

Auf einem einzelnen Computer:

Get-LocalGroupMember -Group "Administrators" |
  Select-Object Name, ObjectClass, PrincipalSource

Get-LocalGroupMember bricht mit einem Fehler ab, wenn die Gruppe verwaiste SIDs enthält (Konten, die aus der Domäne gelöscht wurden). In dem Fall weichen Sie auf net localgroup Administrators oder eine Abfrage über ADSI aus und behandeln jede verwaiste SID als Bereinigungsposten.

Für die gesamte Flotte führen Sie dieselbe Abfrage über Ihr Verwaltungswerkzeug aus (Hardwareinventur in Configuration Manager, ein Intune-Wartungsskript oder Invoke-Command gegen eine Liste von Computern) und sammeln die Ausgabe zentral:

$computers = Get-ADComputer -SearchBase "OU=Workstations,DC=corp,DC=example" -Filter * |
  Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $computers -ScriptBlock {
  Get-LocalGroupMember -Group "Administrators" -ErrorAction SilentlyContinue |
    Select-Object @{n="Computer";e={$env:COMPUTERNAME}}, Name, ObjectClass
} | Export-Csv .\local-admins.csv -NoTypeInformation

Sortieren Sie die Ergebnisse in drei Kategorien:

Domain Users oder Authenticated Users in der lokalen Administratorengruppe kommt häufiger vor, als es sollte, oft durch eine einzige Zeile in einem jahrealten Startskript. Damit ist jeder Benutzer überall Admin; beheben Sie das also zuerst.

Schritt 2: Herausfinden, warum Benutzer Admin sind

Ermitteln Sie für jeden Benutzer in der Kategorie „Einzelne Benutzer“ den Grund, bevor Sie das Recht entziehen. Typische Gründe und was sie ersetzt:

• Software installieren. Veröffentlichen Sie sie im Unternehmensportal, im Softwarecenter oder in einem kuratierten winget-Repository, verteilt im Systemkontext.
• Drucker und Treiber. Verteilen Sie Drucker und paketierte Treiber zentral. Schwächen Sie nicht zum Ausgleich die Point-and-Print-Einschränkungen.
• Entwicklerwerkzeuge. Entwickler brauchen häufig für eine Handvoll Werkzeuge erhöhte Rechte (Hyper-V, WSL-Features, lokale Zertifikate, Debugger). Lösen Sie das mit Erhöhungsregeln, einer eigenen Entwicklungs-VM oder einem separaten Admin-Konto auf einem separaten Gerät.
• Fachanwendungen, die „Admin brauchen“. Meist schreibt die Anwendung nach Program Files oder HKLM. Process Monitor zeigt genau, wohin; Änderungsrechte auf einen Ordner oder Schlüssel sind weit sicherer als Admin-Rechte auf dem ganzen Computer.
• Netzwerkeinstellungen, Zeitzone, VPN ändern. Standardbenutzer können die Zeitzone bereits ändern, und die meisten VPN-Clients laufen als Dienst. Testen Sie, bevor Sie etwas annehmen.

Eine zweiwöchige Umfrage, in der Sie Benutzer mit Admin-Rechten fragen, wofür sie diese genutzt haben, kombiniert mit Softwareinstallationsprotokollen, zeigt meist, dass die meisten sie nie gebraucht haben.

Schritt 3: Mitgliedschaft per Gruppenrichtlinie erzwingen

Benutzer einmal zu entfernen genügt nicht; eine Richtlinie muss die Gruppe verwalten, damit sie nicht zurückdriftet.

Option A: Gruppenrichtlinieneinstellungen (GPP). Legen Sie unter Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups ein neues Element Local Group an:

• Aktion: Update
• Gruppenname: Administrators (built-in)
• Delete all member users und Delete all member groups aktivieren
• Die gewünschten Mitglieder hinzufügen: Ihre Tier-2-Admin-Gruppe und, falls Sie ihn über den Namen verwalten, den integrierten Administrator

Bei jeder Aktualisierung wird die Gruppe geleert und aus der Liste neu aufgebaut. Mehrere GPP-Elemente können dieselbe Gruppe adressieren, und mit der Zielgruppenadressierung auf Elementebene können Sie beispielsweise eine Labor-Admin-Gruppe nur auf Laborcomputern hinzufügen.

Option B: Restricted Groups. Fügen Sie unter Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups die Gruppe Administrators hinzu und füllen Sie Members of this group aus. Das ersetzt die Mitgliedschaft vollständig. Es ist einfach und zuverlässig, wenn ein einziges GPO die Gruppe verwaltet; setzen jedoch mehrere GPOs Members of this group für dieselbe Gruppe, gewinnt nur das zuletzt angewendete, und das überrascht viele.

Entscheiden Sie sich für einen Mechanismus, verknüpfen Sie ihn mit der Arbeitsplatz-OU und stellen Sie sicher, dass er greift, bevor Sie irgendjemanden manuell entfernen. Andernfalls fügt die nächste Richtlinienaktualisierung aus einem älteren GPO womöglich Personen wieder hinzu.

Schritt 4: Mitgliedschaft mit Intune erzwingen

Für in Microsoft Entra eingebundene und hybride Geräte, die mit Intune verwaltet werden, verwenden Sie Endpoint security > Account protection > Local user group membership. Dies nutzt den Richtlinien-CSP LocalUsersAndGroups. Jede Regel hat eine Aktion:

Zur Vereinheitlichung der Administratorengruppe entspricht Add (Replace) den Restricted Groups. Nehmen Sie alles auf, was bleiben soll, einschließlich des integrierten Administrators und Ihrer Supportgruppe, denn alles, was nicht aufgeführt ist, wird entfernt.

Verhindern Sie anschließend, dass beim Join neue Admins entstehen:

• Setzen Sie im Microsoft Entra Admin Center unter Devices > Device settings die Option Registering user is added as local administrator on the device during Microsoft Entra join auf None (oder Selected für eine kleine Gruppe). Das betrifft nur Geräte, die nach der Änderung eingebunden werden.
• Setzen Sie in den Bereitstellungsprofilen von Windows Autopilot User account type auf Standard.
• Verwenden Sie für Supportmitarbeitende die Rolle Microsoft Entra Joined Device Local Administrator, statt einzelne Personen zu jedem Gerät hinzuzufügen. Sie gilt für alle in Entra eingebundenen Geräte und lässt sich nicht auf eine Teilmenge beschränken; Änderungen greifen erst, nachdem ein neues Primary Refresh Token ausgestellt wurde (bis zu 4 Stunden) und sich der Benutzer ab- und wieder angemeldet hat.

Für eine Eingrenzung auf Gerätegruppen fügen Sie Microsoft-Entra-Gruppen (per SID) über die oben genannte Richtlinie „Local user group membership“ zur Administratorengruppe hinzu. Windows wertet höchstens 20 Entra-Gruppen für Admin-Rechte aus, und diese gruppenbasierte Methode gilt nicht für hybrid in Microsoft Entra eingebundene Geräte.

Schritt 5: Einen kontrollierten Erhöhungsweg bereitstellen

Manche Benutzer werden bestimmte Dateien weiterhin mit erhöhten Rechten ausführen müssen. Microsoft Intune Endpoint Privilege Management (EPM), lizenziert über die Intune Suite, Intune Plan 2 oder als Add-on und seit Juli 2026 in Microsoft 365 E5 enthalten, erlaubt einem Standardbenutzer, eine genehmigte Datei erhöht auszuführen, ohne Administrator zu sein. Sie konfigurieren zwei Richtlinientypen:

• Richtlinie für Erhöhungseinstellungen: aktiviert EPM auf dem Gerät und legt die Standardantwort für Erhöhungen bei Dateien fest, auf die keine Regel passt (verweigern, Benutzerbestätigung verlangen oder Supportgenehmigung verlangen).
• Richtlinie für Erhöhungsregeln: Regeln pro Datei, abgeglichen über Dateiname, Hash, Signaturzertifikat und Version, mit dem Erhöhungstyp automatisch, vom Benutzer bestätigt (optional mit Begründung und Windows-Authentifizierung) oder vom Support genehmigt.

Bevorzugen Sie Regeln aus Zertifikat plus Dateiname für signierte Herstellertools und Hash-Regeln für interne Hilfsprogramme. Vermeiden Sie Regeln, die Skripthosts, cmd.exe, powershell.exe, mmc.exe oder Installationsprogramme erhöhen, die beliebige Kindprozesse starten können: Eine erhöhte Shell ist nichts anderes als lokale Admin-Rechte unter anderem Namen.

Ohne EPM bleibt als Rückfallebene ein Helpdesk-Prozess, bei dem ein Techniker das LAPS-Kennwort des Geräts in die UAC-Abfrage eingibt. Das Kennwort wird danach durch die Aktion nach der Authentifizierung automatisch rotiert.

Schritt 6: Einen Notfallzugang behalten

Planen Sie für den Tag, an dem ein Gerät die Vertrauensstellung zur Domäne verliert oder Entra ID nicht erreicht. Das Notfallkonto eines Arbeitsplatzes ist sein von LAPS verwalteter lokaler Administrator: eindeutig pro Gerät, abrufbar durch die Lesergruppe des Helpdesks, nach der Verwendung rotiert. Stellen Sie sicher, dass dieses Konto in der Gruppenmitgliedschaftsrichtlinie aus Schritt 3 bzw. 4 enthalten ist und dass ihm die Netzwerk- und RDP-Anmeldung verweigert wird, damit es nur an der Konsole funktioniert.

Was kaputtgeht

• Selbst installierte Software und Browsererweiterungen, die sich computerweit installieren. Rechnen Sie in den ersten zwei Wochen mit einer Welle von Anfragen; der Katalog aus Schritt 2 fängt die meisten auf.
• Anwendungen, die zur Laufzeit in geschützte Speicherorte schreiben. Sie schlagen entweder fehl oder schreiben stillschweigend in den virtualisierten Speicher (siehe UAC und Administrator protection). Korrigieren Sie die Berechtigungen für den konkreten Pfad.
• Von Benutzern angelegte geplante Aufgaben und Skripte, die mit höchsten Rechten liefen. Überführen Sie die legitimen in eine verwaltete Verteilung.
• Gewohnheiten des Helpdesks. Techniker, die es gewohnt sind, ihr eigenes Domain-Admin-Konto auf dem Computer eines Benutzers einzutippen, müssen auf LAPS oder ein Tier-2-Konto umsteigen. Diese Änderung ist schon für sich ein Sicherheitsgewinn.

Überprüfen

1. Führen Sie die Inventur aus Schritt 1 erneut aus, nachdem die Richtlinie greift. Mitglieder dürfen nur noch die in der Richtlinie festgelegten sein.
2. Änderungen überwachen. Aktivieren Sie Audit Security Group Management unter Advanced Audit Policy Configuration. Das Sicherheitsprotokoll erfasst dann das Ereignis 4732 (ein Mitglied wurde einer sicherheitsaktivierten lokalen Gruppe hinzugefügt) und 4733 (ein Mitglied wurde entfernt). Alarmieren Sie auf 4732 für die Administratorengruppe außerhalb Ihres Änderungsprozesses.
3. Intune-Berichte prüfen. Für die Richtlinie „Local user group membership“ zeigt der Status pro Gerät Konflikte und Fehler, typischerweise durch ein GPO, das auf co-verwalteten Geräten gegen die Intune-Regel arbeitet.
4. Das Benutzertoken bestätigen. Auf dem Gerät eines Benutzers darf whoami /groups für die eigene Sitzung des Benutzers BUILTIN\Administrators überhaupt nicht aufführen.

Checkliste

• Flottenweite Inventur der Mitgliedschaft in der lokalen Administratorengruppe erhoben
• Domain Users, Authenticated Users und verwaiste SIDs entfernt
• Gründe für Admin-Rechte katalogisiert und ersetzt (Softwarekatalog, Drucker, Ordnerberechtigungen)
• Eine einzige Richtlinie verwaltet die Administratorengruppe (GPP, Restricted Groups oder Intune Replace)
• Entra-Join und Autopilot machen Benutzer nicht mehr zu lokalen Admins
• EPM oder ein LAPS-basierter Helpdesk-Prozess für Erhöhungen, keine gemeinsamen Admin-Konten
• LAPS-Konto als Notfallkonto in der Richtlinie enthalten, Netzwerkanmeldung verweigert
• Ereignis 4732 für die lokale Administratorengruppe überwacht

Das Entziehen lokaler Admin-Rechte gehört zu den unscheinbarsten und zugleich wirksamsten Projekten eines Windows-Härtungsplans. Sobald Benutzer Standardbenutzer sind, lassen sich Maßnahmen wie die Anwendungssteuerung wirklich durchsetzen, weil ein Standardbenutzer sie nicht mehr abschalten kann.