Endpoint Privilege Management (EPM) & lokale Adminrechte entfernen

Was ist EPM

Endpoint Privilege Management (EPM) ist eine Zusatzfunktion von Microsoft Intune, mit der deine Anwender als Standardbenutzer ohne lokale Administratorrechte arbeiten und trotzdem die wenigen Aufgaben erledigen können, die erhöhte Rechte verlangen. Klassische Kandidaten dafür sind Anwendungsinstallationen (etwa die Microsoft 365 Apps), das Aktualisieren von Gerätetreibern oder das Ausführen bestimmter Windows-Diagnosen.

Der Grundgedanke ist Least Privilege: Statt einer breiten Anwenderbasis dauerhaft Adminrechte zu geben, laufen alle mit minimalen Rechten – und nur die einzelnen, IT-freigegebenen Aktionen werden bei Bedarf temporär erhöht (elevated). Genau das ist ein Kernbaustein einer Zero-Trust-Strategie: Weniger stehende Privilegien bedeuten weniger Angriffsfläche und geringeres Risiko für laterale Bewegung im Netzwerk.

Hinweis: EPM ist ein kostenpflichtiges Intune-Add-on (Intune Suite oder Stand-alone) und gilt ausschließlich für Windows. Details zur Lizenzierung stehen weiter unten im Kapitel Voraussetzungen.

Dieser Artikel führt durch die Funktionsweise von EPM, die Elevation-Typen und Regel-Fähigkeiten, das Reporting sowie Voraussetzungen und Lizenzierung. Am Ende zeige ich, wie du mit dem LocalUsersAndGroups CSP lokale Administratorkonten sauber aus der Administratorengruppe entfernst – der zweite Baustein neben EPM, um Anwender wirklich zu Standardbenutzern zu machen.

Key Features & Benefits

Die wichtigsten Eigenschaften von EPM auf einen Blick:

• Standardbenutzer als Default. Anwender erledigen ihre Aufgaben ohne lokale Adminrechte.
• Just-in-Time-Elevation. Anwender können gezielt IT-freigegebene Binaries oder Skripte temporär erhöhen – nicht mehr und nicht weniger.
• Policy-basierte Kontrolle. Admins definieren Einstellungen und Regeln, die Bedingungen und Verhalten der Elevation steuern – mit granularer Regelbildung, die sich an den Bedürfnissen der Organisation ausrichtet.
• Audit-Logging & Reporting. Intune protokolliert jede Elevation mit detaillierten Metadaten.
• Zero-Trust-Ausrichtung. Least-Privilege-Zugriff und minimiertes Risiko lateraler Bewegung sind direkt eingebaut.

EPM Fundamentals: Wie EPM funktioniert

Eine Elevation lässt sich auf zwei Wegen auslösen:

• Automatisch (ohne Zutun des Anwenders) oder
• benutzerinitiiert (der Anwender stößt die Erhöhung selbst an).

EPM wird über zwei Policy-Typen konfiguriert, die sich jeweils an Gruppen von Benutzern oder Geräten zuweisen lassen:

• Elevation settings policy – steuert den EPM-Client, das Reporting-Level und das Standardverhalten bei Elevationen.
• Elevation rules policy – definiert das Elevation-Verhalten für einzelne Binaries oder Skripte anhand von Kriterien.

Für die eigentliche Erhöhung auf dem Gerät nutzt der EPM-Dienst bei den meisten Elevation-Typen ein virtuelles Konto, das vom angemeldeten Benutzerkonto isoliert ist. Weder das virtuelle Konto noch das Benutzerkonto werden dabei der lokalen Administratorengruppe hinzugefügt. Die einzige Ausnahme ist der Typ Elevate as current user (siehe unten).

Der EPM-Client wird automatisch installiert, sobald einem Gerät oder Benutzer eine Elevation settings policy zugewiesen wird. Er läuft als Dienst „Microsoft EPM Agent Service" und legt seine Binaries hier ab:

C:\Program Files\Microsoft EPM Agent

Ablauf im Kern: Der EPM-Client wird ausgelöst, prüft die zutreffenden Regeln und ermöglicht anschließend die Elevation gemäß Regel bzw. Standardverhalten.

Der EPM-Ablauf: Eine Elevation wird entweder vom EPM-Treiber (automatisch) oder vom Anwender initiiert. EPM prüft auf einen Regel-Treffer – ohne Treffer greift das Default Elevation Behavior, mit Treffer wird die Elevation ermöglicht.

Elevation Types

Eine Elevation-Regel erlaubt EPM, das Ziel der Regel als Proxy mit Administratorrechten auf dem Gerät auszuführen – im Ergebnis hat die Anwendung dann volle administrative Fähigkeit auf dem Gerät. Mit Ausnahme von Elevate as current user nutzt EPM dazu das virtuelle Konto, was die erhöhten Aktionen vom Benutzerprofil isoliert, die Exposition benutzerspezifischer Daten reduziert und das Risiko einer Privilege Escalation senkt.

Für das Elevation-Verhalten gibt es folgende Optionen:

• Automatic (Automatisch): EPM erhöht diese Anwendungen ohne Zutun des Anwenders. Breit gefasste Regeln in dieser Kategorie können die Sicherheitslage der Organisation großflächig beeinflussen – entsprechend vorsichtig einsetzen.

• User confirmed (Benutzerbestätigt): Der Anwender nutzt das neue Rechtsklick-Kontextmenü „Mit erhöhtem Zugriff ausführen" (Run with elevated access). Zusätzlich lässt sich eine weitere Validierung erzwingen – per Authentifizierungsabfrage, geschäftliche Begründung (Business Justification) oder beides. Das ist eine zusätzliche Schutzschicht, weil der Anwender die Elevation bewusst quittieren muss.

  

  User-confirmed-Elevation: Der EPM-Client zeigt den verifizierten Publisher der Anwendung und lässt den Anwender die Erhöhung bewusst per „Continue" bestätigen.

  

  Optional lässt sich zusätzlich eine geschäftliche Begründung (Business Justification) erzwingen – der Anwender muss vor dem Absenden einen Grund angeben.

• Elevate as current user: Dieser Typ führt den erhöhten Prozess unter dem eigenen Konto des angemeldeten Benutzers aus – nicht über das virtuelle Konto. Damit bleiben Profilpfade, Umgebungsvariablen und persönliche Einstellungen erhalten, was die Kompatibilität mit Tools und Installern sicherstellt, die auf das aktive Benutzerprofil angewiesen sind. Da die Benutzeridentität vor und nach der Elevation identisch bleibt, sind auch die Audit-Trails konsistent und exakt. Der Typ verlangt eine erneute Anmeldung über Windows Authentication (gültige Credentials) vor der Erhöhung.

  Der Preis: Weil der erhöhte Prozess den vollen Kontext des Benutzers erbt, vergrößert sich die Angriffsfläche und die Isolation von den Benutzerdaten sinkt.

  Wichtige Überlegungen:

  • Kompatibilitätsbedarf: Nur nutzen, wenn die Elevation über das virtuelle Konto zu Anwendungsfehlern führt.
  • Eng scopen: Regeln auf vertrauenswürdige Binaries und Pfade begrenzen, um das Risiko zu senken.
  • Security-Tradeoff: Bewusst sein, dass dieser Modus die Exposition benutzerspezifischer Daten erhöht.

  Tipp: Wenn Kompatibilität kein Thema ist, gib der Elevation über das virtuelle Konto den Vorzug – sie ist sicherer.

• Support approved (Support-genehmigt): Der Anwender beantragt die erhöhte Ausführung einer Anwendung. Ein Administrator kann den Request genehmigen; anschließend wird der Anwender benachrichtigt, dass er die Elevation auf dem Gerät erneut versuchen kann.

  

  Support-approved-Elevation: Nach dem Absenden bestätigt EPM, dass die Anforderung übermittelt wurde – der Anwender kann die App ausführen, sobald der Administrator sie genehmigt hat.

• Deny (Verweigern): Eine Deny-Regel identifiziert eine Datei, die EPM in einem erhöhten Kontext blockiert. So lässt sich sicherstellen, dass bekannte oder potenziell schädliche Software nicht erhöht ausgeführt werden kann.

Der EPM-Client lässt sich mit einer Standard-Elevation-Antwort (Default Elevation Behavior) betreiben oder mit spezifischen Regeln, die die jeweilige Elevation-Antwort erlauben.

Rule Capabilities

EPM-Elevation-Regeln lassen sich anhand eines oder mehrerer Attribute bilden (Dateiname, Pfad usw.). Die wichtigsten Fähigkeiten:

• Child Process Controls (Kindprozess-Steuerung): Wird ein Prozess durch EPM erhöht, steuerst du, wie EPM die Erzeugung von Kindprozessen behandelt – granulare Kontrolle über Subprozesse, die deine erhöhte Anwendung erzeugt.
• Argument Support: Nur bestimmte Parameter/Argumente einer Anwendung dürfen erhöht werden.
• File Hash Support: Die Anwendung wird über den Hash der Datei identifiziert.
• Publisher Certificate Support: Regeln, die dem Publisher-Zertifikat der Anwendung vertrauen – kombinierbar mit weiteren Attributen.

Vorsicht bei Zertifikatsregeln: Eine Zertifikatsregel kann jede von diesem Zertifikat signierte App zur Elevation erlauben. Bei Herstellern, die alle ihre Apps mit demselben Zertifikat signieren, ist das ein Risiko – hier eng scopen.

Supported file types

EPM kann folgende Dateitypen erhöhen:

Reporting

EPM liefert Reports, mit denen du das Deployment vorbereitest, überwachst und den Betrieb nachvollziehst. Berichtet werden zwei Kategorien:

• Unmanaged Elevation (nicht verwaltet): Alle Datei-Elevationen, die ohne EPM passieren – typischerweise, wenn ein Benutzer mit Adminrechten die Windows-Standardaktion „Als Administrator ausführen" nutzt.
• Managed Elevation (verwaltet): Jede Elevation, die EPM ermöglicht – sei es als Ergebnis einer Elevation-Regel oder als Teil des Standard-Elevation-Verhaltens.

Die Unterscheidung ist wichtig: Der Unmanaged-Report zeigt dir, wo heute noch außerhalb von EPM erhöht wird – also, wo du künftig Regeln bauen oder Adminrechte entziehen solltest.

Getting started

EPM wird aus dem Microsoft Intune Admin Center administriert. Der High-Level-Prozess für den Einstieg:

1. License EPM & Plan
   • License EPM: Bevor du EPM-Policies nutzen kannst, musst du EPM im Tenant als Intune-Add-on lizenzieren.
   • Plan for EPM: Vorab die wichtigsten Anforderungen und Konzepte klären (siehe Checkliste unten).
2. Deploy EPM: Auditing aktivieren, Regeln erstellen, Deployment überwachen.
3. Manage EPM: Nach dem Rollout Support-genehmigte Requests und Elevationen überwachen, Regeln pflegen und aktualisieren, Benutzerprivilegien regelmäßig prüfen.

Der High-Level-Prozess als Kreislauf: License and Plan (lizenzieren, Prerequisites, Fundamentals), Deploy (Auditing, Settings- und Rules-Policy) und Manage (Requests, Monitoring, Regelpflege, Privilegien-Review).

Planning Checklist

Vor dem Rollout solltest du folgende Punkte durchgehen:

• Technische und lizenzrechtliche Prerequisites im Tenant prüfen.
• Ziel-Personas definieren, um Regeln logisch nach diesen Personas zu gruppieren.
• Ein solides Verständnis von Elevation settings und Elevation rules aufbauen, insbesondere:
  • Standard-Elevation-Einstellungen und Diagnosedaten-Sammlung.
  • Definition von Elevation-Dateien über File Hash, Metadaten oder Zertifikate.
  • Wie Zertifikatsregeln jede von diesem Zertifikat signierte App elevieren lassen können – Vorsicht bei Herstellern, die alles mit demselben Zertifikat signieren.
  • Argument Support der Regeln und Child-Process-Optionen.
  • Die Elevation-Typen.
  • Wie Regelkonflikte bei überlappenden Zuweisungen aufgelöst werden.
• Die richtige Balance zwischen Sicherheit und Flexibilität für deine Organisation und Personas finden.
• Eine belastbare Rollout-Strategie aufsetzen: Stakeholder-Management, Endanwender-Kommunikation, Schulung und Monitoring.

Voraussetzungen, Lizenzierung und Requirements

Lizenzierung

EPM erfordert eine Add-on-Lizenz zusätzlich zu Microsoft Intune Plan 1. Du hast zwei Optionen:

• eine Stand-alone-Lizenz, die nur EPM ergänzt, oder
• EPM als Teil der Microsoft Intune Suite.

Requirements

EPM stellt folgende Anforderungen:

• Microsoft Entra joined oder Microsoft Entra hybrid joined.
• Geräte via Microsoft Intune Enrollment oder als Configuration-Manager-co-managed (keine Workload-Anforderung).
• Ein unterstütztes Betriebssystem (siehe unten).
• Freie Sicht (clear line of sight) ohne SSL-Inspection zu den erforderlichen Endpunkten.

Nicht unterstützt: Workplace-Join-Geräte und Azure Virtual Desktop. Windows 365 wird mit einer unterstützten OS-Version unterstützt.

Unterstützte Betriebssysteme:

Wichtig – Windows 10 End of Support: Am 14. Oktober 2025 hat Windows 10 das Support-Ende erreicht und erhält keine Qualitäts- und Feature-Updates mehr. Windows 10 ist in Intune weiterhin eine erlaubte Version – solche Geräte können sich noch enrollen und geeignete Features nutzen, aber die Funktionalität ist nicht garantiert und kann variieren.

Weitere wichtige Punkte:

• Elevation settings policies werden auf Geräten mit nicht unterstützter OS-Version als „not applicable" gemeldet.
• EPM ist nur mit 64-Bit-Architekturen kompatibel – inklusive Arm64.

Government cloud support

EPM wird in folgenden souveränen Cloud-Umgebungen unterstützt:

• U.S. Government Community Cloud (GCC) High
• U.S. Department of Defense (DoD)

Important concepts

Bevor du EPM breit ausrollst, solltest du die folgenden Konzepte und ihre Auswirkungen auf deine Umgebung sicher verstehen:

• Run with elevated access: Das Rechtsklick-Kontextmenü, das erscheint, sobald EPM auf einem Gerät aktiv ist. Wird es genutzt, prüft das Gerät seine Elevation rules policies auf einen Treffer, um zu entscheiden, ob und wie die Datei in einem administrativen Kontext erhöht werden darf. Gibt es keine passende Regel, greift das Default Elevation Behavior aus der Elevation settings policy.

  

  Sobald EPM aktiv ist, erscheint im Rechtsklick-Kontextmenü der Eintrag „Ausführen mit erhöhten Zugriffsberechtigungen" – der Einstiegspunkt für benutzerinitiierte Elevationen.

• File elevation & elevation types: EPM erlaubt Anwendern ohne Adminrechte, Prozesse im administrativen Kontext auszuführen (siehe Elevation Types).

• Child process controls: Jede Elevation-Regel kann zusätzlich das Verhalten für Kindprozesse festlegen, die der erhöhte Prozess erzeugt.

• Client-side components: Um EPM zu nutzen, provisioniert Intune einen kleinen Satz an Komponenten auf dem Gerät, die die Elevation-Policies empfangen und durchsetzen. Diese Komponenten werden nur provisioniert, wenn eine Elevation settings policy eintrifft, die EPM auch tatsächlich aktivieren will.

• Managed vs. Unmanaged Elevations: Begriffe aus dem Reporting – Managed meint jede von EPM ermöglichte Elevation, Unmanaged jede außerhalb von EPM (z. B. per „Als Administrator ausführen").

EPM und User Account Control (UAC)

EPM und die eingebaute User Account Control (UAC) sind getrennte Features mit unterschiedlicher Funktion. Wenn du Anwender auf Standardbenutzer umstellst und EPM einsetzt, kannst du das Standard-UAC-Verhalten für Standardbenutzer bewusst anpassen, um Verwirrung zu reduzieren und die User Experience zu verbessern.

Hinweis: EPM greift nicht in UAC-Aktionen ein, die ein Administrator auf dem Gerät ausführt.

EPM Policies

EPM nutzt zwei Policy-Typen, die zusammen festlegen, wie eine Datei-Elevation behandelt wird, wenn ein Standardbenutzer administrative Rechte anfordert:

• Elevation settings policy
• Elevation rules policy

Zusätzlich unterstützt EPM eine Reusable settings group, in der du Publisher-Zertifikate ablegst und über mehrere Regeln bzw. Regel-Policies hinweg referenzierst.

Policy conflict handling

Bis auf die folgenden Sonderfälle werden Policy-Konflikte bei EPM wie jeder andere Policy-Konflikt behandelt.

Elevation settings policy: Empfängt ein Gerät zwei Elevation settings policies mit widersprüchlichen Werten, fällt der EPM-Client auf das Standardverhalten zurück, bis der Konflikt aufgelöst ist.

Hinweis: Steht die Einstellung Enable Endpoint Privilege Management im Konflikt, ist das Standardverhalten des Clients EPM aktiviert.

Elevation rules policy: Empfängt ein Gerät zwei Regeln, die dieselbe Anwendung adressieren, werden beide auf dem Gerät konsumiert. Zur Auflösung nutzt EPM diese Logik:

1. Regeln mit dem Typ Deny haben immer Vorrang – die Elevation wird verweigert.
2. Regeln, die einem Benutzer zugewiesen sind, haben Vorrang vor Regeln, die einem Gerät zugewiesen sind.
3. Regeln mit definiertem Hash gelten immer als die spezifischste Regel.
4. Trifft mehr als eine Regel zu (ohne Hash), gewinnt die Regel mit den meisten definierten Attributen (am spezifischsten).
5. Bleiben danach immer noch mehrere Regeln übrig, entscheidet diese Reihenfolge: User confirmed → Elevate as current user → Support approved → Automatic.

Hinweis: Existiert für eine per Run with elevated access angeforderte Elevation keine Regel, greift das Default Elevation Behavior.

Security recommendations

Für ein sicheres EPM-Deployment gelten diese Empfehlungen:

• Sichere Standard-Elevation-Antwort setzen. Setze das Default-Verhalten auf „Require support approval" oder „Deny" statt auf „Require user confirmation". So bleibt Elevation über vordefinierte Regeln für bekannte Binaries kontrolliert – das Risiko, dass Anwender beliebige oder schädliche Executables elevieren, sinkt.

• File-Path-Restriktionen in allen Regeltypen fordern. Der File Path ist zwar optional, aber ein wichtiger Sicherheitscheck – besonders bei automatischer Elevation oder Wildcard-Attributen. Zeigt der Pfad auf einen Ort, den Standardbenutzer nicht verändern können (z. B. ein gesichertes Systemverzeichnis), lässt sich verhindern, dass Executables oder ihre abhängigen Binaries vor der Elevation manipuliert oder ausgetauscht werden. Das gilt für automatisch aus Reports erzeugte und für manuell erstellte Regeln.

  Wichtig: Dateien auf Netzwerkfreigaben werden nicht unterstützt und dürfen nicht in Regeldefinitionen verwendet werden.

• Installer- und Runtime-Elevation trennen. Installer-Elevation eng kontrollieren (unautorisierte Softwareinstallation verhindern), Runtime-Elevation minimieren (Angriffsfläche reduzieren).

• Strengere Regeln für Hochrisiko-Apps. Für Anwendungen mit breitem Zugriff oder Skripting-Fähigkeit (Webbrowser, PowerShell) restriktivere Regeln setzen. Bei PowerShell möglichst skript-spezifische Regeln, damit nur vertrauenswürdige Skripte erhöht laufen.

• Bei Migration von Drittprodukten neu anfangen. EPM arbeitet anders als Drittprodukte – starte mit einer Audit-Policy, baue Regeln aus den Reports und nutze Support approved elevation, wenn für eine Datei noch keine Regel existiert, ein Anwender sie aber braucht.

Role-based access control (RBAC)

Zum Verwalten von EPM braucht dein Konto eine Intune-RBAC-Rolle mit den passenden Rechten. Die relevanten Permissions:

• Endpoint Privilege Management Policy Authoring – für Policies, Daten und Reports. Unterstützt: View Reports, Read, Create, Update, Delete, Assign.
• Endpoint Privilege Management Elevation Requests – für Support-genehmigte Elevation-Requests. Unterstützt: View elevation requests, Modify elevation requests.

Du kannst diese Permissions in eigene Custom-Rollen packen oder eine Built-in-Rolle nutzen:

EpmTools PowerShell-Modul

Jedes Gerät, das EPM-Policies erhält, installiert den EPM-Agent – inklusive des EpmTools-PowerShell-Moduls. Damit lassen sich Probleme diagnostizieren und File-Attribute direkt aus einer Anwendung auslesen, um Detection-Regeln zu bauen.

Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'

Hinweis: Windows auf Arm64 erfordert die Nutzung von Windows PowerShell x64.

Verfügbare Cmdlets:

Konfiguration & Deployment

Für das Deployment aktivierst du zuerst das Reporting, dann baust du aus den Reports die Elevation-Regeln. Drei Bausteine sind relevant:

• Windows elevation settings policy
• Windows elevation rules policy
• Reusable settings groups (optionale Konfiguration für deine Elevation-Regeln)

Deployment-Phasen

EPM kontrolliert die App-Elevation; parallel steuert Local Users and Groups (LocalUsersAndGroups CSP, siehe unten) die lokale Administratorengruppe und den Übergang von Administratoren zu Standardbenutzern. Die empfohlenen Phasen:

Die fünf empfohlenen Deployment-Phasen von Auditing über Persona-Identifikation und Regelbau bis hin zum Monitoring und dem Prüfen der Benutzerprivilegien.

1. Phase 1 – Auditing: EPM-Client und Reporting-Sammlung über eine Elevation settings policy aktivieren.
2. Phase 2 – Persona-Identifikation: Benutzergruppen mit gemeinsamen Anforderungen identifizieren.
3. Phase 3 – Build rules: Aus den EPM-Reports Elevation-Regeln je Persona bauen.
4. Phase 4 – Monitoring: Regeln iterieren und verfeinern, neue Szenarien erkennen.
5. Phase 5 – Benutzerprivilegien prüfen: Benutzer optional per Local Users and Groups von Administrator auf Standardbenutzer umstellen. Support approved elevation aktivieren, damit Anwender für nicht abgedeckte Apps Elevation anfordern können.

Die Phasen 2 bis 5 laufen kontinuierlich weiter, damit deine Anwender dauerhaft mit Least Privilege im Sinne von Zero Trust arbeiten.

Typische Deployment-Szenarien

Rules: Elevation-Regeln bauen

Für viele Regeln brauchst du zwei Dinge einer Anwendung: das Publisher-Zertifikat und den File Hash. Beides lässt sich per PowerShell auslesen. Den Hash allein liefert Get-FileHash:

Get-FileHash "C:\Program Files (x86)\Simple IP Config\Simple IP Config.exe" -Algorithm SHA256

Praktischer ist ein kleines Skript, das beides in einem Rutsch erzeugt – das Publisher-Zertifikat als .cer-Datei und den SHA256-Hash. Pfade ($ExePath, $CertOutPath) vor dem Ausführen anpassen:

<#
.SYNOPSIS
  Liest Publisherzertifikat und File Hash einer .exe-Datei aus.

.DESCRIPTION
  Dieses Skript liest das Publisherzertifikat und den File Hash einer .exe-Datei.
  Beides wird fuer die Konfiguration von Elevation Rules Policies in
  Endpoint Privilege Management genutzt. $ExePath und $CertOutPath anpassen.
#>

$ExePath     = "C:\Program Files\beispiel\beispiel.exe"
$CertOutPath = "C:\temp\Certificate.cer"

# Publisherzertifikat als .cer exportieren
Get-AuthenticodeSignature $ExePath |
    Select-Object -ExpandProperty SignerCertificate |
    Export-Certificate -Type CERT -FilePath $CertOutPath

# SHA256-Hash ausgeben
Get-FileHash $ExePath | Select-Object Hash

Die exportierte .cer-Datei referenzierst du beim Anlegen einer Regel als Publisher-Zertifikat (idealerweise über eine Reusable settings group), den Hash trägst du als File-Hash-Attribut ein. Kombinierst du beides mit einem File Path in einem gesicherten Verzeichnis, entsteht eine spezifische, manipulationsresistente Regel.

Praxis-Tipp: Get-FileAttributes aus dem EpmTools-Modul (siehe oben) nimmt dir dieselbe Arbeit direkt auf dem Endgerät ab – inklusive Extraktion von Publisher- und CA-Zertifikat.

Entfernen lokaler Adminkonten (LocalUsersAndGroups CSP)

EPM allein macht deine Anwender noch nicht zu Standardbenutzern. Solange ein Konto noch Mitglied der lokalen Gruppe Administratoren ist, umgeht es EPM schlicht über „Als Administrator ausführen". Der zweite, entscheidende Schritt ist deshalb, die lokale Administratorengruppe aufzuräumen – so, dass nur noch kontrollierte Konten wie das LAPS-Konto (und der eingebaute Administrator) übrig bleiben.

Dafür nutzt du den LocalUsersAndGroups Policy CSP. Ab Windows 10, Version 20H2 ist er der empfohlene Weg (statt des älteren RestrictedGroups-CSP).

Wichtig: Wende nicht LocalUsersAndGroups und RestrictedGroups gleichzeitig auf demselben Gerät an – das ist nicht unterstützt und führt zu unvorhersehbaren Ergebnissen. Auch mehrere LocalUsersAndGroups-Policies pro Gerät sind nicht erlaubt (Konflikt in Intune).

Die drei Aktionen verstehen

In der Policy wählst du die lokale Gruppe, die auf dem Endgerät editiert werden soll (z. B. die Administratorengruppe), und legst eine Aktion fest:

Kurz gesagt: Update (U) ändert gezielt einzelne Mitglieder und lässt den Rest in Ruhe. Replace (R) ersetzt die komplette Mitgliedschaft durch das, was in der Policy steht – alles Nicht-Aufgeführte fliegt raus.

Der User-Selection-Type kann auf einen vorhandenen User/eine Gruppe aus Entra/AD zeigen oder auf Manuell stehen, sodass du den Account selbst definierst – zum Beispiel den LAPS-Admin.

Konfiguration in Intune (Custom-Profil per OMA-URI)

Wird der CSP nicht über eine Katalog-Einstellung angeboten, hinterlegst du ihn als Custom-Konfigurationsprofil:

• Devices → Configuration profiles → Create profile
• Plattform Windows 10 and later, Profil Templates → Custom
• OMA-URI-Setting hinzufügen mit dieser OMA-URI:

./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

• Data type: String (XML) – hier lädst du die weiter unten gezeigte XML hoch.
• Profil an die passende Geräte-Gruppe zuweisen.

Scope: Der CSP gilt pro Gerät (Device-Scope), unterstützt in Windows Pro, Enterprise, Education sowie IoT Enterprise.

Die XML-Struktur

Das Konfigurations-XML folgt diesem Schema:

<GroupConfiguration>
    <accessgroup desc = "">
        <group action = ""/>
        <add member = ""/>
        <remove member = ""/>
    </accessgroup>
</GroupConfiguration>

Bedeutung der Elemente:

• accessgroup desc – Name oder SID der zu konfigurierenden lokalen Gruppe. Die eingebaute Administratorengruppe adressierst du am robustesten über ihre wohlbekannte SID S-1-5-21-<Domäne>-500.
• group action – U (Update) oder R (Restrict/Replace).
• add member / remove member – SID oder Name des Mitglieds. Benutzerkonten im Format AzureAD\userUPN (z. B. AzureAD\admin@contoso.com); für Entra-Gruppen ist die Gruppen-SID zwingend (Gruppennamen werden nicht unterstützt, SID via Graph-API aus securityIdentifier).

Verarbeitungsreihenfolge: Die Einträge werden in der angegebenen Reihenfolge abgearbeitet – mit Ausnahme der R-Aktionen, die immer zuletzt greifen (sie „gewinnen"). remove member ist bei der R-Aktion ungültig und wird ignoriert.

Beispiel 1 – Nur LAPS-Admin behalten, Rest entfernen (Replace)

Ziel: Sicherstellen, dass außer LAPS (bzw. EPM) keine weiteren Adminkonten mehr in der Administratorengruppe stehen. Dazu ersetzt du die komplette Mitgliedschaft per R-Aktion. Wichtig: Bei R musst du den eingebauten Administrator immer mit angeben – er muss zwingend Mitglied der Gruppe bleiben, sonst schlägt die Aktion fehl.

<GroupConfiguration>
    <accessgroup desc = "S-1-5-21-2222222222-3333333333-4444444444-500">
        <group action = "R" />
        <add member = "Administrator"/>
        <add member = "LapsAdmin"/>
    </accessgroup>
</GroupConfiguration>

Nach dem Anwenden enthält die lokale Administratorengruppe ausschließlich den eingebauten Administrator und das LapsAdmin-Konto – alle zuvor vorhandenen Adminkonten sind entfernt.

Schutz vor Aussperren: Windows blockiert das Entfernen des eingebauten Administrator-Kontos aus der Administratorengruppe auf SAM-/OS-Ebene (Fehler 0x55b / 1371 ERROR_SPECIAL_ACCOUNT). Deshalb bei R immer den eingebauten Administrator in add member aufführen.

Beispiel 2 – Gezielt ein Konto entfernen (Update)

Willst du die restliche Gruppe nicht anfassen und nur ein bestimmtes Altkonto loswerden, nutzt du U mit remove member:

<GroupConfiguration>
    <accessgroup desc = "S-1-5-21-2222222222-3333333333-4444444444-500">
        <group action = "U" />
        <add member = "AzureAD\lapsadmin@contoso.com"/>
        <remove member = "AzureAD\alt.admin@contoso.com"/>
    </accessgroup>
</GroupConfiguration>

Hier bleibt die übrige Mitgliedschaft erhalten; nur alt.admin wird entfernt und lapsadmin sichergestellt. Das Entfernen eines Nicht-Mitglieds ist unkritisch – es passiert schlicht nichts und es entsteht kein Fehler.

Reihenfolge des Vorgehens: In einem laufenden Migrationsprojekt empfiehlt sich zunächst die Update-Variante (gezielt Altkonten entfernen, LAPS-Admin sicherstellen). Erst wenn die Umgebung sauber ist und du die vollständige Kontrolle willst, wechselst du auf Replace, um jede zukünftige, ungewollte Gruppenmitgliedschaft automatisch zu entfernen.

Zusammenspiel: EPM + LocalUsersAndGroups

Beide Bausteine greifen ineinander und ergeben erst zusammen echtes Least Privilege:

Ergebnis: Deine Anwender laufen als Standardbenutzer, benötigte Aufgaben werden per EPM just-in-time und auditierbar erhöht, und ein lokales Admin-Konto existiert nur noch kontrolliert über LAPS. Genau das ist der Zielzustand einer Zero-Trust-Endpoint-Strategie.

Diese Anleitung ergänzt die übrigen Hardening-Artikel rund um Intune – EPM und das Entfernen lokaler Adminrechte sind zusammen einer der wirksamsten Hebel, um die Angriffsfläche auf Endpunkten dauerhaft zu senken.