Optimiertes Privileged Access Management bei aktueller Version des Betriebssystems
Lokale Administratorrechte waren bisher im Grunde genommen ein Kompromiss zwischen Geschwindigkeit und Sicherheit. Das Dumme: Moderne Angriffe zielen genau auf diese Privilegien. Gestohlene Zugangstoken, Manipulation von Sicherheitsfunktionen, unerwünschte Persistenz etc. sind immer häufiger die Folgen. Windows stellt nun für erhöhte Aktionen einen temporären, isolierten Admin-Modus bereit und räumt die Rechte danach wieder ab. Geschützt werden damit vor allem System und Anmeldeinformationen wie Token und Secrets.
Was macht der neue Administratorenschutz konkret? Nun, beim Anmelden arbeitet der Nutzer zunächst ohne Privilegien. Fordert ein Prozess erhöhte Rechte an, muss die Identität über Windows Hello PIN oder Passwort bestätigt werden. Erst danach erzeugt Windows ein verdecktes, vom System verwaltetes Administratorkonto mit eigenem Profilkontext. Daraus entsteht ein isoliertes Admin‑Token nur für den anfragenden Prozess. Nach Abschluss wird das Token verworfen.
Bisher konnten Administratoren ein sogenanntes Split‑Token‑Modell nutzen. Hierbei kamen sowohl ein Standard‑ als auch ein erhöhtes Token parallel zum Einsatz. Der optimierte Administratorenschutz erzwingt damit eine klare Sitzungstrennung – und der erhöhte Kontext erhält ein getrenntes Benutzerprofil. Das verhindert Daten‑ und Credential‑Lecks und macht Elevation zu einer echten Sicherheitsgrenze. Angreifer können dadurch nurmehr deutlich schwerer ohne Interaktion „von unten nach oben“ springen.
Einordnung: Administratorenschutz, LAPS, UAC und EPM
Wie aber ist das Zusammenspiel mit den bisherigen Security-Klassikern? Die altbekannte Local Administrator Password Solution (LAPS) löst das Problem statischer, wiederverwendeter Kennwörter lokaler Admin‑Konten durch regelmäßige Rotation – sie adressiert also den Kontext „Wer kennt das Passwort?“. Der Administratorenschutz hingegen ändert das „Wie“ der Erhöhung. Er ersetzt die bisherige Elevation durch eine temporäre, isolierte Admin‑Sitzung.
Die User Account Control (UAC) bleibt als Benutzerinteraktion relevant, quasi als Defense‑in‑Depth. Das Endpoint Privilege Management (EPM) steuert weiterhin granulare Elevations für Standardnutzer und Apps. Wichtig für die Praxis: Der Administratorenschutz reduziert die Angriffsfläche von Admin‑Konten; EPM beantwortet, welche Tasks ohne Voll‑Admin möglich sein sollen. Beides ergänzt sich – die Policies müssen demnach aufeinander abgestimmt werden.
Voraussetzungen und Rollout‑Wege für W11-Adminschutz
Administrator protection wird für Windows 11 schrittweise ausgerollt und ist laut Microsoft derzeit noch als Preview dokumentiert. Frühere Build-Zuordnungen aus den Release Notes wurden zwischenzeitlich wieder zurückgezogen. Die Aktivierung erfolgt lokal über die Windows‑Sicherheit im Bereich „Kontoschutz“ oder per Gruppenrichtlinie bei Sicherheitsoptionen und „Benutzerkontensteuerung: Typ des Administrativbestätigungsmodus konfigurieren“; von dort geht es zum „Admin Approval Mode mit Administratorenschutz“. Zudem lässt sich das Prompt-Verhalten konfigurieren. Alternativ/ergänzend erfolgt die Verteilung über Intune (Settings Catalog) oder per CSP; dabei nicht vergessen: Gerät neu starten.
Die Konfigurationsdetails für Intune: Im Settings Catalog stehen unter „Local Policies Security Options“ zwei zentrale Parameter bereit – erstens der Modus der Admin Approval Mode‑Verarbeitung inklusive Administratorenschutz und zweitens das Prompt‑Verhalten; also, ob die Eingabe von Anmeldeinformationen gefordert wird oder eine Zustimmung ausreicht. Für Rollouts empfiehlt sich eine gestaffelte Zuweisung.
Wichtig: Nicht jedes Gerät eignet sich für eine sofortige Aktivierung. Microsoft nennt hier Systeme wie Hyper-V oder WSL als Fälle, die vorab gesondert geprüft werden sollten. In solchen Umgebungen empfiehlt sich ein zurückhaltender Test mit klar definierten Rückfalloptionen, bevor der Schutz breit ausgerollt wird.
Praxistipp: In 5 Schritten zum neuen Administratorenschutz bei Windows 11
Damit die mögliche Verbesserung der IT-Sicherheit zügig und wirkungsvoll in die eigene Infrastruktur gelangen kann, helfen folgende fünf Punkte:
- Inventarisieren: Welche Nutzer arbeiten heute mit lokalen Adminrechten? Welche Tools verlangen Elevation, welche können im Benutzerkontext laufen?
- Pilot definieren: Pilotgruppe auswählen; Windows Hello einsatzbereit machen; Kommunikation/Helpdesk vorbereiten.
- Policies umsetzen: Administratorenschutz aktivieren, Prompt‑Verhalten testen (Anmeldeinformationen vs. Zustimmung), Ausnahmen dokumentieren.
- Kompatibilität prüfen: Installer, Treiber‑Tools, Legacy‑Anwendungen. Besonderheit: getrennte Profile – Netzwerkpfade und SSO ggf. anpassen.
- Ausrollen und überwachen: ETW-Events (Microsoft-Windows-LUA, 15031/15032) für Monitoring/Audits protokollieren und an das zentrale SIEM weiterleiten; Helpdesk-Playbooks für verweigerte Elevation, fehlende Netzpfade im erhöhten Kontext und blockierte Updater hinterlegen; Rollback vorbereiten.
Tipp: In frühen Phasen kann eine temporäre Deaktivierung pro Gerätegruppe sinnvoll sein, um kritische Geschäftsprozesse nicht zu gefährden.
Dabei gilt es auch, einige bekannte Stolpersteine zu beachten. Durch die Trennung von Benutzer- und Admin-Profil etwa stehen im erhöhten Kontext keine SSO-Anmeldedaten zur Verfügung. Dadurch sind gemappte Netzlaufwerke häufig nicht sichtbar oder nur eingeschränkt nutzbar. Installationsquellen sind deshalb lokal bereitzustellen; alternativ lassen sich die betreffenden Schritte gezielt im Benutzerkontext ausführen. Geplante Aufgaben, die „mit höchsten Privilegien“ laufen sollen, werden am besten als SYSTEM oder über ein dediziertes Dienstkonto konfiguriert – ohne dauerhaftes lokales Admin-Token, weil es die Angriffsfläche unnötig vergrößert.
Weiterhin erscheint je nach Windows-Build der GUI-Schalter in Windows-Sicherheit zeitversetzt. Ausschlaggebend ist jedoch, dass die zugrunde liegenden Richtlinien korrekt gesetzt und wirksam sind; nach der Aktivierung ist ein Neustart erforderlich. Für eine saubere Nachverfolgung sollten Erhöhungen und Fehlversuche im SIEM sichtbar sein, inkl. Gerät, Benutzer, Prozess. Ein häufiges Problem sind zudem Installer, die im Hintergrund auf Netzfreigaben zugreifen oder SSO im erhöhten Kontext erwarten. In solchen Fällen helfen drei Wege: Installationspakete lokal bereitstellen, sich im erhöhten Kontext erneut authentifizieren oder das Setup so paketieren, dass es ohne Abhängigkeit von Benutzer-SSO auskommt.
Fazit: Mehr IT-Security auf OS-Ebene
Der Administratorenschutz in Windows 11 verschiebt den Standard von „Admin steht bereit“ zu „Admin nur, wenn nötig und strikt isoliert“. Für Unternehmen bedeutet das: weniger Angriffsfläche bei gleicher Handlungsfähigkeit. Wer lokale Adminrechte noch breit vergibt, sollte jetzt Pilot und geordneten Rollout starten – mit klaren Policies und Monitoring im SIEM sichtbar machen. So entsteht ein belastbarer, alltagstauglicher Least‑Privilege‑Betrieb. Dabei wünschen wir wie immer: Viel Erfolg!
FAQ Administratorenschutz bei Windows 11
Was ist der Administratorenschutz in Windows 11?
Ein temporärer, isolierter Admin-Kontext. Rechte gelten nur für die konkrete Aktion und werden danach wieder entzogen. Ergebnis: weniger Angriffsfläche bei gleicher Produktivität.
Worin unterscheidet sich Administratorenschutz von LAPS?
LAPS verwaltet und rotiert die lokalen Admin-Passwörter pro Gerät. Der Administratorenschutz regelt das Wie der Erhöhung: just-in-time, getrennt vom Benutzerprofil, ohne dauerhaftes Admin-Token.
Wie aktiviere ich den Administratorenschutz in der Praxis?
Über Windows-Sicherheit im Bereich Kontoschutz, per Gruppenrichtlinie in den Sicherheitsoptionen oder über Intune im Settings Catalog bzw. via CSP. Prompt-Verhalten festlegen, Richtlinien zuweisen, Gerät neu starten.
Welche Voraussetzungen gelten und welche Builds werden unterstützt?
Windows 11 ab 24H2/25H2, Windows Hello für die Bestätigung und eine saubere Richtlinienverteilung. Nach Aktivierung ist ein Neustart einzuplanen; der GUI-Schalter kann je nach Build zeitversetzt erscheinen.
Wie überwache ich Erhöhungen im Betrieb?
ETW-Events erfassen und ans zentrale SIEM weiterleiten: Microsoft-Windows-LUA mit den IDs 15031 und 15032. So werden erfolgreiche und fehlgeschlagene Erhöhungen korreliert und alarmiert.
