Lokale Administratorrechte sind ein Dauerproblem im Client-Management. Nutzer fordern sie an, weil bestimmte Anwendungen oder Installationsroutinen sie voraussetzen. IT-Abteilungen gewähren sie – nicht selten sogar dauerhaft – , weil die Alternative (jede Elevationsanforderung manuell bearbeiten) zu aufwändig erscheint.
Das Ergebnis sind Geräteparks, in denen ein erheblicher Anteil der Nutzer lokale Admins sind. Dies stellt ein erhebliches Sicherheitsrisiko dar, das jede Endpunkt-Schutzmaßnahme partiell unterläuft. Microsoft Intune Endpoint Privilege Management (EPM) bietet einen technisch sauberen Ausweg.
Was EPM leistet und was nicht
EPM steht zwar in enger Verwandtschaft zu Windows Laps, deckt aber doch ein anderes Szenario ab. Während Laps im Prinzip nur dafür sorgt, dass die Passwörter vorhandener lokaler Administratorkonten zentral im AD oder (besser) Entra ID gespeichert und regelmäßig rotiert werden, bzw. bei der neusten Laps-Version entsprechende lokale Admin-Konten explizit angelegt werden, sofern nicht vorhanden, ermöglicht es EPM, bestimmte Anwendungen oder Prozesse mit erhöhten Rechten auszuführen, ohne dass der Nutzer selbst lokaler Admin ist. Die Elevation erfolgt kontrolliert, auf Basis von konfigurierten Regeln und wird vollständig geloggt.
EPM ist jedoch weder ein Tool zur Rechtevergabe auf Datei- oder Ordnerebene, noch ein allgemeines Privilege-Access-Management-System und auch kein Ersatz für Just-in-Time-Administratorzugriff auf Server. EPM ist spezifisch für den Windows-Client-Kontext und für die Frage: „Welche Anwendungen brauchen erhöhte Rechte, und wie gewähre ich diese gezielt?“ gedacht.
EPM ist Bestandteil der Microsoft Intune Suite (Add-on zu Intune Plan 1) für derzeit rund 7 € pro Nutzer/Monat oder als separates EPM-Add-on buchbar. Es setzt Windows 10 21H2 oder neuer voraus und erfordert, dass die Geräte bei Intune registriert sind.
Die drei Elevations-Modi
EPM kennt drei Modi, die pro Regel konfiguriert werden:
Automatic Elevation: Die hierfür „definierte“ Anwendung wird immer mit erhöhten Rechten gestartet, ohne Nutzerinteraktion. Geeignet für bekannte, vertrauenswürdige Anwendungen, die regelmäßig erhöhte Rechte benötigen (z. B. bestimmte Gerätetreiber-Installer, Konfigurations-Tools).
User Approved Elevation: Der Nutzer muss die Elevation aktiv bestätigen. Das läuft ganz ähnlich wie bei der bekannten UAC-Abfrage, aber kontrollierter. Der Anwender kann optional eine Geschäftsbegründung eingegeben, die dann im Log erscheint. Geeignet für Anwendungen, die nur gelegentlich erhöhte Rechte brauchen.
Support Approved Elevation: Der Nutzer beantragt die Elevation, aber ein Administrator muss sie im Intune-Portal genehmigen. Erst nach Genehmigung kann die Anwendung mit erhöhten Rechten gestartet werden. Dieser Modus ist der restriktivste und eignet sich für seltene, riskante Szenarien, weil er den meisten Overhead erzeugt.
Elevation Rules konfigurieren
Die Konfiguration erfolgt im Intune-Portal unter *Endpunktsicherheit → Endpoint Privilege Management → Richtlinien“. Hier erstellen Sie Elevation Rules wie bei Intune üblich in Form von Richtlinien, die sie dann Gerätegruppen oder Nutzergruppen zuweisen. Als Plattform steht allerdings wie auch bei Laps ausschließlich Windows zur Verfügung. Als Profiltypen stehen „Richtlinie für rechte Erweiterungsregeln“ und „Richtlinie für rechte Erweiterungseinstellungen“ zur Verfügung
Die „Richtlinie für Rechteerweiterungseinstellungen“ (Elevation Settings Policy) ist die Grundlage. Sie aktiviert EPM auf dem Gerät und legt das Standardverhalten für alle Dateien fest, die keine spezifische Regel (s. u) haben.
Die „Richtlinie für Rechteerweiterungsregeln“ (Elevation Rules Policy) definiert „konkrete Regeln“ (s. o) für einzelne Dateien/Apps (z. B. welche Datei wie erhöht werden darf).
Die folgende Tabelle erläutert den Unterschied.
| Aspekt | Richtlinie für Rechteerweiterungseinstellungen | Richtlinie für Rechteerweiterungsregeln |
| Hauptzweck | EPM aktivieren/deaktivieren + Standardverhalten für nicht-geregelte Dateien | Spezifische Regeln für bestimmte Dateien/Apps |
| Was wird konfiguriert? | – EPM aktiviert/deaktiviert – Standardantwort (z. B. alle Anforderungen ablehnen, Support-Genehmigung erforderlich) – Berichterstattung (Reporting) |
– Identifikation der Datei (Dateiname, Hash, Zertifikat, Pfad, Version …) – Erhöhungstyp (Automatisch, Benutzerbestätigt, Support-genehmigt, Ablehnen) – Verhalten von Kindprozessen etc. |
| Wann wird sie benötigt? | Immer – ohne diese Richtlinie funktioniert EPM auf dem Gerät nicht | Optional, aber notwendig, sobald Sie gezielt Apps erlauben wollen |
| Priorität | Gilt nur, wenn keine passende Regel existiert | Regeln haben Vorrang vor dem Standardverhalten |
In einer konkreten Rechteerweiterungsregel hingegen definieren Sie also, „welche Anwendung“ unter „welchen Bedingungen“ mit Elevation gestartet werden darf. Die Identifikation der Anwendung kann über mehrere Attribute erfolgen:
- Dateipfad und Dateiname: (z. B. `C:\Program Files\Vendor\Setup.exe`)
- Dateihash (SHA-256): die sicherste Methode, da sie exakt diese Version der Datei identifiziert
- Zertifikatsignatur: alle mit einem bestimmten Zertifikat signierten Anwendungen einer Organisation
- Produktname und Herstellerangabe: aus den Datei-Metadaten
In produktiven Umgebungen empfiehlt sich die Kombination aus Dateipfad und Zertifikatsignatur oder , für maximale Sicherheit, Dateihash. Ein Dateipfad allein ist zu wenig. Eine manipulierte Datei am selben Pfad würde ebenfalls mit Elevation gestartet.
Ein konkretes Regelbeispiel könne vereinfacht so aussehen:
- Name: Netzwerktreiber-Update
- Anwendung: C:\Temp\NetworkDriverSetup.exe
- Identifikation: SHA-256 Hash + Publisher-Zertifikat
- Elevations-Typ: User Approved
- Begründung erforderlich: Ja
Der EPM-Client auf dem Endpunkt
Sobald eine EPM-Richtlinie zugewiesen ist, erscheint auf dem Windows-Client im Kontextmenü von ausführbaren Dateien die Option „Mit Endpoint Privilege Management ausführen“. Für Automatic-Elevation-Rules ist diese Option transparent, d. h. der Nutzer sieht dann nur, dass die Anwendung startet. Bei „User-Approved-Elevations“ erscheint ein Dialog, bei „Support-Approved“ ein Anfrage-Workflow.
Wichtig: Nur Anwendungen, die explizit in einer Elevation Rule definiert sind, können über EPM mit erhöhten Rechten gestartet werden. Alles andere läuft weiterhin im Standard-Nutzer-Kontext. Das ist der Kern des Zero-Trust-Prinzips für Endpunkte, also kein implizites Vertrauen, nur explizit erlaubte Ausnahmen.
Reporting und Audit
Jede Elevation , egal ob „automatic“, „user approved“ oder „support approved“ wird im Intune-Portal unter „Endpunktsicherheit → Endpoint Privilege Management → Berichte“ protokolliert. Der Bericht enthält:
- Benutzername und Gerät
- Name der ausgeführten Anwendung
- Zeitstempel der Elevation
- Elevations-Typ
- Angegebene Geschäftsbegründung (falls konfiguriert)
- Regelname, der die Elevation ausgelöst hat
Diese Daten sind auch über „Microsoft Intune Data Warehouse“ und „Azure Monitor Logs“ abrufbar, was die Integration in SIEM-Systeme ermöglicht.
Für die Praxis empfehle ich, das Elevation-Log regelmäßig nach folgenden Kriterien auszuwerten.
- Welche Anwendungen werden am häufigsten elevated?
- Gibt es Elevations außerhalb der definierten Regeln (über Support Approved)?
Häufige Support-Approved-Anfragen für dieselbe Anwendung sind ein Signal, dass eine Automatic- oder User-Approved-Rule sinnvoll wäre.
Typische Anwendungsfälle
Typische Einsatzfälle Für EPM wären zum Beispiel die Folgenden.
Gerätetreiber-Installer: Hardware-Hersteller liefern Setup-Routinen, die lokale Admin-Rechte erfordern. Mit EPM lässt sich der Installer des Herstellers über Zertifikatsignatur identifizieren und für User-Approved-Elevation freigeben.
Ältere Business-Anwendungen: Software aus den 2000er- und 2010er-Jahren wurde häufig so entwickelt, dass sie Admin-Rechte für den normalen Betrieb erwartet, sogar wenn nur einzelne Aktionen (z. B. Konfiguration speichern in `Program Files`) die Rechte tatsächlich benötigen. EPM ermöglicht Elevation gezielt für diese Aktionen, statt den Nutzer dauerhaft zum Admin zu machen.
Installationsroutinen im Self-Service: Mit dem Microsoft Company Portal (Intune App) können Nutzer Anwendungen selbst installieren. Wenn der Installer erhöhte Rechte benötigt, kann EPM diese transparent bereitstellen, ohne dass der Nutzer Admin ist.
Häufige Fallstricke
Es gibt allerdings auch typische Stolpersteine beim Einführen von EPM. Hier dazu einige Beispiele
Zu breite Regeln: Eine Regel, die alle Anwendungen eines Herstellers per Publisher-Zertifikat abdeckt, ist zu großzügig. Wird das Herstellerzertifikat kompromittiert oder der Hersteller veröffentlicht eine schadhafte Anwendung, greift die Elevation ebenfalls. In diesen Falle wirken Hashes oder kombinierte Kriterien präziser.
Kein Audit-Prozess: Nicht selten werden EPM-Logs zwar generiert, aber nicht ausgewertet. Ohne regelmäßigen Review bleibt unklar, ob die konfigurierten Rules den tatsächlichen Bedarf abdecken oder ob es Missbrauch gibt.
EPM als Übergangslösung missbraucht: In manchen Umgebungen werden vorübergehend großzügige EPM-Rules definiert, nach dem Motto „bis wir die Anwendung modernisiert haben“. Diese bleiben dann häufig dauerhaft bestehen. EPM-Rules sollten regelmäßig reviewt und nicht benötigte Rules deaktiviert werden.
Nicht alle Geräte sind kompatibel: EPM erfordert Windows 10 21H2 oder neuer. Ältere Geräte in der Flotte erhalten keine EPM-Richtlinien, d. h. für Geräten diesen Typs müsste dann eine separate Strategie existieren.
Migration von lokalen Admin-Konten zu EPM
Der Übergang von einer Umgebung mit weitverbreiteten lokalen Adminrechten zu EPM sollte schrittweise erfolgen. Ich empfehle dazu folgende Phasen.
- Discovery: Stellen Sie fest, welche Nutzer derzeit lokale Admins sind. Dazu gibt es verschiedene Möglichkeiten wie zum Beispiel Intune-Berichte oder PowerShell-Abfragen.
- Anwendungsanalyse: Prüfen Sie, für welche Anwendungen/Aktionen die Admin-Rechte wirklich genutzt wurden. Das lässt sich über Process-Monitoring (z. B. Defender for Endpoint Advanced Hunting) erheben.
- Rules erstellen: Erstellen Sie erst dann EPM-Regeln für die identifizierten Anwendungen.
- Pilotgruppe: Entfernen Sie dann lokale Admin-Rechte bei der Pilotgruppe und aktivieren dort EPM-Rules. Danach müssen sie das Supportaufkommen beobachten.
- Breiter Rollout: Nach erfolgreicher Pilotphase können Sie EPM auf alle Nutzer ausweiten.
Fazit
Endpoint Privilege Management ist kein Allheilmittel für alle Szenarien, in denen Nutzer heute Admin-Rechte haben. Es ist aber die sauberste verfügbare Lösung für den Windows-Client-Bereich. Die Kombination aus gezielten Elevation Rules, vollständigem Audit-Trail und Integration in Intune macht EPM zu einem wichtigen Baustein einer Zero-Trust-Endpoint-Strategie.
Voraussetzung ist die Bereitschaft, den initialen Aufwand für die Anwendungsanalyse und Rule-Konfiguration zu investieren und die Regeln auch danach auch zu pflegen.