Intune-Kurs · Teil 26 von 45 · Block C: Konfiguration & Richtlinien
Was Sie in dieser Sektion lernen
- Grundkonzepte
- Praxis-Implementierung
- Best Practices
- Troubleshooting
ca. 16 Min. Lesezeit · Alle Sektionen im Überblick
Einleitung
Auf jedem Windows-Gerät existiert mindestens ein Konto mit lokalen Administratorrechten. Und genau dieses Konto ist in der Praxis eines der größten Sicherheitsrisiken der gesamten Client-Landschaft – nicht, weil es existiert, sondern weil es in den meisten Umgebungen mit einem statischen, überall identischen Passwort betrieben wird. Der klassische Zustand sieht so aus: ein Image, ein lokaler Admin, ein Passwort, verteilt über tausend Geräte. Wer ein einziges Gerät kompromittiert, besitzt damit faktisch Administratorzugriff auf die gesamte Flotte. Ransomware-Kampagnen leben von genau diesem Muster.
Die Local Admin Password Solution (LAPS) ist Microsofts Antwort auf dieses Problem: Jedes Gerät erhält ein eigenes, kryptografisch zufälliges Passwort, das automatisch rotiert und zentral verschlüsselt gespeichert wird. Der Zugriff darauf ist an Berechtigungen gebunden und wird protokolliert. Seit April 2023 ist Windows LAPS als echtes Betriebssystem-Feature in Windows integriert – und über den Einstellungskatalog von Microsoft Intune mit wenigen Klicks enterprise-weit ausrollbar. Kein Agent, keine Zusatzinstallation, keine Lizenzkosten für das Feature selbst.
Diese Sektion behandelt die aktuelle Windows-LAPS-Generation – nicht den klassischen „Legacy-LAPS“ von 2015. Wir gehen den kompletten Weg: Architektur und Grundkonzepte, Implementierung über Intune für reine Entra-Umgebungen, der Hybrid-Fall mit Sicherung ins lokale Active Directory, Berechtigungsmodell, Rotationssteuerung, Best Practices und ein strukturierter Troubleshooting-Guide für die Fehlerbilder, die in der Praxis wirklich auftreten.
Grundkonzepte
Das Problem: viele Geräte, ein Geheimnis
Warum ist ein statisches lokales Admin-Passwort so gefährlich? Der typische Angriffspfad läuft so ab: Ein Nutzer öffnet eine präparierte Datei, ein ungepatchtes Gerät wird per Exploit getroffen oder eine gestohlene Anmeldeinformation wird eingespielt. Der Angreifer hat danach nur Nutzerrechte – aber auf demselben Gerät liegt das lokale Admin-Konto. Werkzeuge wie Mimikatz lesen Anmeldeinformationen direkt aus dem Speicher des LSASS-Prozesses, sobald sich jemand mit dem lokalen Admin interaktiv angemeldet hat. War das Passwort auf allen Geräten identisch, genügt ein einziger erfolgreicher Diebstahl, um lateral durch die gesamte Organisation zu wandern: von Arbeitsplatz zu Arbeitsplatz, bis irgendwo ein Domain-Admin-Konto zu finden ist.
Manuelle Rotation löst das Problem nicht. Wer schon einmal versucht hat, 500 lokale Admin-Passwörter „von Hand“ zu verwalten, weiß: Das wird nie getan – und wenn doch, landet die Liste in einer Excel-Datei auf einem Netzlaufwerk. Das ist ein Sicherheitsgewinn von exakt null. LAPS automatisiert den gesamten Zyklus: Erzeugung, Speicherung, Rotation und kontrollierter Abruf.
Legacy-LAPS und Windows-LAPS: der wichtige Unterschied
Der klassische Microsoft LAPS aus dem Jahr 2015 war ein kleines On-Premise-Toolset: ein Client-Side-Extension für Gruppenrichtlinien, das das Passwort im Active Directory im Klartext-Attribut ms-Mcs-AdmPwd am Computerobjekt ablegte. Es funktionierte gut, war aber fest an die GPO-Welt und ein lokales AD gebunden. Microsoft hat dieses Tool abgekündigt und mit Windows LAPS einen kompletten Neubau als natives Betriebssystem-Feature nachgeliefert. Die Unterschiede im Überblick:
- Legacy-LAPS: separate Installation (CSE), Konfiguration nur per GPO, Speicherung nur im Active Directory, Klartext-Attribut
ms-Mcs-AdmPwd, eigenes PowerShell-Modul (AdmPwd.PS). - Windows-LAPS: nativ im Betriebssystem ab Windows 11 22H2 (für damals unterstützte Windows-10-Versionen über das kumulative Update von April 2023 nachgereicht – Windows 10 ist seit Oktober 2025 regulär außer Support), Konfiguration per GPO oder MDM/CSP und damit vollwertig in Intune, Speicherung wahlweise in Microsoft Entra ID oder im Active Directory, verschlüsselte Speicherung inklusive Passworthistorie, neue
msLAPS-*-Attribute, integriertes PowerShell-Modul.
Für alle, die mit Intune arbeiten, ist die Botschaft eindeutig: Windows LAPS ist der Standardweg. Bestehende Legacy-LAPS-Umgebungen sollten auf Windows LAPS migriert werden – dazu später mehr bei den Best Practices.
Architektur: Wie Windows LAPS funktioniert
Die Architektur besteht aus vier Bausteinen, die man sauber auseinanderhalten sollte:
- Richtlinienquelle: Windows LAPS wird über eine Richtlinie konfiguriert – in unserem Fall über Intune, das die Einstellungen über den MSFT-LAPS-CSP (Configuration Service Provider) an das Gerät liefert. In Hybrid-Szenarien kann dieselbe Konfiguration auch per GPO kommen. Wichtig: eine Quelle pro Gerät, niemals GPO und Intune parallel (dazu mehr im Troubleshooting).
- LAPS-Engine: Die eigentliche Logik läuft nativ im Betriebssystem. Sie erzeugt das Passwort kryptografisch zufällig, setzt es lokal, sichert es beim Backup-Ziel und rotiert es nach Ablauf der konfigurierten Zeit. Die Verarbeitung findet bei Richtlinienempfang, bei Ablauf des Passwortalters und auf Anforderung statt.
- Speicherung: Bei Sicherung nach Entra ID wird das Passwort stets verschlüsselt am Geräteobjekt im Entra-Mandanten abgelegt. Bei Sicherung ins Active Directory schreibt die Engine die
msLAPS-*-Attribute am Computerobjekt – wahlweise im Klartext-AttributmsLAPS-Passwordoder verschlüsselt inmsLAPS-EncryptedPassword, inklusive optionaler Passworthistorie. - Abruf-Ebene: Das ist der entscheidende Unterschied zur „Passwort-Excel“: Das Lesen des Passworts ist an Berechtigungen geknüpft und wird protokolliert. In Entra ID entschlüsseln autorisierte Rollen den Blob on demand; im AD steuern ACLs am Computerobjekt, wer lesen darf.
Ein wichtiges Detail für das Verständnis der Rotation: Ein Gerät rotiert sein Passwort erst, wenn es das neue Passwort erfolgreich sichern konnte. Offline-Geräte behalten also ihr aktuelles Passwort und rotieren beim nächsten Kontakt mit Entra ID beziehungsweise dem Domain Controller. Damit ist ausgeschlossen, dass ein Gerät ein Passwort setzt, das nirgends mehr auffindbar ist. Umgekehrt gilt: Wer ein Passwort abruft, kann sich darauf verlassen, solange das Gerät erreichbar war.
Drei Schutzmechanismen, die man kennen muss
Windows LAPS bringt drei Mechanismen mit, die über die reine Rotation hinausgehen und bewusst konfiguriert werden sollten:
- Post-Authentication-Reset: Wird ein Passwort abgerufen und entschlüsselt, markiert das System es als „verwendet“. Nach einer konfigurierbaren Frist (in Stunden) rotiert das Gerät das Passwort automatisch nach. Ein abgelesenes Passwort hat damit nach jeder Benutzung ein eingebautes Verfallsdatum.
- Password-Expiration-Protection: Verhindert, dass das verwaltete Passwort vor Ablauf der regulären Lebensdauer von lokaler Seite geändert wird – ein typischer Trick, um den LAPS-Mechanismus auszuhebeln, indem Angreifer oder „hilfsbereite“ Skripte das Passwort vorher umsetzen.
- Verschlüsselung im AD: Im AD-Modus kann das Passwort verschlüsselt statt im Klartext-Attribut abgelegt werden, inklusive konfigurierbarer Historie. Wer ohnehin nach Entra ID sichert, braucht das nicht – in reinen AD-Abteilungen, etwa für Domain Controller, ist es Pflicht.
Voraussetzungen im Überblick
- Betriebssystem: Windows 11 ab Version 22H2 nativ; Windows 10 nur noch eingeschränkt, da der reguläre Support im Oktober 2025 endete.
- Gerätestatus: Für die Sicherung nach Entra ID muss das Gerät eine Entra-Geräteidentität haben – reine Entra-joined-Geräte sind der Standardfall, Hybrid-joined-Geräte können ebenfalls nach Entra ID sichern.
- Lizenzierung: Windows LAPS selbst kostet nichts. Für das Entschlüsseln der in Entra ID gespeicherten Passwörter braucht die abrufende Person jedoch eine Microsoft Entra ID P1-Lizenz; für den Abruf über das Intune-Portal zusätzlich eine Intune-Rolle mit dem entsprechenden Recht.
- AD-Modus: erweitertes AD-Schema (msLAPS-*-Attribute) und berechtigte Computerobjekte – Details in Schritt 4 der Implementierung.
Praxis-Implementierung
Szenario und Zielbild
Wir implementieren das Standardszenario, das für die meisten Intune-Umgebungen gilt: eine Flotte von Entra-joined Windows-11-Geräten, verwaltet ausschließlich über Microsoft Intune, ohne lokales Active Directory als Backup-Ziel. Zielkonfiguration: Rotation alle 30 Tage, Passwortlänge 20 Zeichen, alle Zeichengruppen aktiviert, Expiration-Protection an, Post-Auth-Reset nach 24 Stunden. Danach schauen wir uns den Hybrid-Fall mit Sicherung ins Active Directory an – der in vielen Unternehmen parallel läuft, etwa für Domain Controller oder Umgebungen, die bewusst am AD festhalten.
Schritt 1: LAPS-Richtlinie im Einstellungskatalog erstellen
Der sauberste Weg führt über den Einstellungskatalog, den du aus den vorangegangenen Sektionen kennst. Im Microsoft Intune Admin Center: Geräte → Konfiguration → Erstellen → Neue Richtlinie. Plattform „Windows 10 und später“, Profiltyp „Einstellungskatalog“. In den Einstellungen suchst du nach „Local Admin Password Solution“ – die Kategorie erscheint direkt und liefert alle relevanten Schalter.
Diese Einstellungen setzt du für unser Szenario:
Backup Password: „Passwörter in Microsoft Entra ID sichern“ (Alternativen: Active Directory oder deaktiviert). Das ist der Hauptschalter – ohne aktives Backup-Ziel passiert nichts.Password Age in Days: 30. Der Standardwert liegt bei 30 Tagen; für Hochsicherheitsbereiche sind auch 7 bis 14 Tage üblich.Password Length in Characters: 20. Der Standard liegt bei 14; da Länge die billigste Entropie ist, empfehlen sich 20 bis 30 Zeichen.Password Complexity: alle Zeichengruppen aktiviert – Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen (intern die Flags a, b, c, d; Standard ist ebenfalls „alle“).Password Expiration Protection: Aktiviert.Post Authentication Reset Delay in Hours: 24. Gibt dem Helpdesk einen Arbeitstag mit dem Passwort, bevor das Gerät automatisch rotiert.Administrator Account Name: optional – standardmäßig verwaltet LAPS den eingebauten Administrator (RID 500). Mehr dazu bei den Best Practices.
Anschließend vergibst du wie gewohnt Assignments auf die Gerätegruppen – im ersten Schritt idealerweise eine Pilotgruppe mit zwei, drei Testgeräten. Nach der Verteilung verarbeitet die LAPS-Engine die Konfiguration innerhalb weniger Minuten.
Alternative: Custom Profile mit OMA-URIs
Wenn du die Konfiguration lieber explizit als OMA-URIs abbildest – etwa für Versionierung als Code oder weil der Einstellungskatalog die Kategorie in deinem Tenant nicht anzeigt – legst du ein Profil vom Typ „Benutzerdefiniert“ an und setzt folgende Werte:
Und weil wir in dieser Masterclass Konfiguration als Code denken: Dasselbe Profil lässt sich über Microsoft Graph direkt erzeugen – hilfreich für automatisierte Tenant-Provisionierung:
Schritt 2: Passwort abrufen – Portal und PowerShell
Sobald ein Gerät die Richtlinie verarbeitet und sein erstes Passwort gesichert hat, liegt der Abruf genau dort, wo der Helpdesk ohnehin arbeitet: im Blatt des jeweiligen Geräts im Intune Admin Center. Unter „Lokales Administratorkennwort“ (im Monitor-Bereich des Geräts) lässt sich das Passwort per Klick anzeigen – und direkt von dort auch eine On-Demand-Rotation auslösen. Wichtig zu wissen: Dieser Portalweg funktioniert ausschließlich für Passwörter, die nach Entra ID gesichert wurden. AD-gesicherte Passwörter erscheinen hier nicht; für sie greift der Werkzeugkasten aus Schritt 4.
Wer den Abruf skripten will – für Automatisierung, eigene Self-Service-Tools oder Audit-Auswertungen – nutzt PowerShell oder Microsoft Graph. Das integrierte Cmdlet authentifiziert dich interaktiv gegen Entra ID und liefert das entschlüsselte Passwort, sofern deine Rolle die Entschlüsselung erlaubt:
Zur Berechtigungsseite: Entschlüsseln dürfen nur rollenautorisierte Personen – etwa die Entra-Rolle „Cloud Device Administrator“ oder Intune-Rollen mit dem Recht zum Anzeigen lokaler Geräteanmeldedaten (View local device credentials). Das ist der Punkt, an dem LAPS von „Passwort-Verwahrung“ zum „Berechtigungsmodell“ wird: Der Helpdesk bekommt eine eigene Rolle, die ausschließlich das Anzeigen erlaubt – nicht mehr und nicht weniger.
Schritt 3: Rotation steuern
Rotation passiert in drei Fällen: automatisch beim Erreichen des konfigurierten Passwortalters, nach einem entschlüsselnden Abruf (nach Ablauf der Post-Authentication-Frist) oder manuell auf Anforderung. Für den manuellen Fall gibt es zwei Wege:
- Intune Admin Center: Remote-Aktion „Kennwort des lokalen Administrators rotieren“ am Gerät. Die Anweisung wird beim nächsten Gerätekontakt ausgeführt – bei einem ausgeschalteten Gerät also mit Verzögerung.
- Lokal auf dem Gerät, etwa im Troubleshooting direkt am Rechner: Das Cmdlet
Reset-LapsPassworderzwingt die sofortige Neuerzeugung,Invoke-LapsPolicyProcessingstößt den gesamten Verarbeitungslauf an.
Schritt 4: Hybrid-Fall – Sicherung ins Active Directory
Der AD-Modus ist relevant, wenn du bewusst On-Premise bleibst oder Geräte ohne Entra-Anbindung verwaltest – und er ist Pflicht für zwei Spezialfälle: Domain Controller (Windows LAPS kann dort zusätzlich das DSRM-Kennwort rotieren, das lokale Admin-Äquivalent auf einem DC – ein oft übersehener Angriffspunkt) und Umgebungen, in denen Berechtigungen strikt über AD-Gruppen und OU-ACLs abgebildet werden.
Die Einrichtung erfolgt in drei Schritten, alle über das in Windows integrierte LAPS-PowerShell-Modul:
Zusätzlich empfiehlt sich das Aktivieren der Auditing-Einstellungen auf der OU (Cmdlet Set-LapsADAuditing), damit jeder Lesezugriff auf die Passwort-Attribute im Sicherheitsprotokoll landet. Auf der Intune-Seite ändert sich gegenüber Schritt 1 nur der Wert von Backup Password: „In Active Directory sichern“ (OMA-URI BackupPassword = 2), plus die Verschlüsselungsoptionen aus der URI-Liste oben. Der Abruf erfolgt dann klassisch am Computerobjekt:
Schritt 5: Verifikation
Vertraue keinem Rollout, das du nicht am Gerät geprüft hast. Die Verifikation ist bewusst einfach gehalten:
Erwartetes Bild: ein Ereignis, das die empfangene Richtlinie bestätigt, eines, das die Passwortgenerierung und den erfolgreichen Backup meldet – und dann das abrufbare Passwort im Intune-Portal. Fehlt eines dieser Glieder, springe direkt in den Troubleshooting-Abschnitt.
Best Practices
Parameter mit Verstand setzen, nicht mit Bauchgefühl
Die drei Stellgrößen Länge, Komplexität und Alter bestimmen die Sicherheit des Systems. Länge ist die wichtigste: Ein rein zufälliges 20-Zeichen-Passwort mit aktivierten Zeichengruppen ist gegen Offline-Brute-Force praktisch immun – Angriffe auf die lokale SAM-Datenbank scheitern hier an der Rechenzeit, nicht am Werkzeug. 14 Zeichen (Standard) sind ordentlich, aber 20 kosten nichts. Beim Alter gilt: 30 Tage sind der übliche Kompromiss aus Sicherheit und Betriebsruhe. Kürzere Zyklen von 7 bis 14 Tagen erhöhen den Schutz, vergrößern aber auch das Fenster, in dem ein Helpdesk-Ticket mit einem veralteten Passwort arbeitet – der Post-Authentication-Reset entschärft genau dieses Risiko.
Benannten Admin-Account statt RID 500 – oder beides bewusst
Standardmäßig verwaltet LAPS das eingebaute Administrator-Konto (RID 500). Dafür spricht die Einfachheit: Das Konto existiert auf jedem Gerät, und LAPS findet es auch nach einer Umbenennung zuverlässig über die bekannte RID. Dagegen spricht ein oft übersehener Punkt: Auf frischen Windows-Installationen ist dieses Konto deaktiviert – und LAPS rotiert nur das Passwort, es aktiviert das Konto nicht. Wer den eingebauten Admin also nie aktiviert hat, fährt mit einem benannten lokalen Admin-Konto besser (z.B. per PowerShell-Skript über Intune angelegt), das dann über Administrator Account Name verwaltet wird. Das schafft zusätzlich Klarheit im Audit: Anmeldungen dieses Kontos lassen sich gezielt überwachen, ohne das Rauschen um die RID 500.
Berechtigungen minimieren und Abrufe überwachen
LAPS verschiebt das Geheimnis vom Endgerät in ein zentrales Verwahrsystem – damit wird die Zugriffskontrolle auf dieses System zum neuen Schutzziel. Konkret: Der Helpdesk bekommt eine eigene Rolle nur für den LAPS-Abruf, idealerweise über Scoped Roles zusätzlich auf konkrete Gerätegruppen begrenzt. Abrufe werden über die Audit-Funktionen in Intune und Entra ID protokolliert – richte darauf eine regelmäßige Kontrolle ein. Und der wichtigste Prozessgriff: Passwörter gehören nie in Tickets, Chats oder Dokumentationen. Ein abgerufenes Passwort ist bis zur Rotation ein schützenswertes Geheimnis mit begrenzter Lebensdauer.
Defense in Depth: LAPS ist ein Baustein, kein Schutzwall
Ein verbreitetes Missverständnis: LAPS schützt nicht davor, dass ein einmal genutztes Passwort aus dem Speicher gelesen wird, wenn sich jemand interaktiv damit anmeldet. Der Schutz von LAPS ist Einzigartigkeit und Rotation – die Speichersicherheit kommt aus anderen Schichten: Credential Guard und LSA Protection gegen LSASS-Zugriffe, ASR-Regeln gegen Credential-Dumping-Werkzeuge und bei RDP-Zugriffen der Restricted-Admin-Modus, der die Übermittlung lokaler Anmeldeinformationen an den Zielhost verhindert. Das Zusammenspiel dieser Schichten behandeln wir an anderer Stelle dieser Masterclass im Detail; hier genügt die Merkregel: LAPS plus Credential Guard plus ASR ergeben erst das vollständige Bild.
Migration von Legacy-LAPS sauber planen
Bestehende Legacy-LAPS-Umgebungen migrierst du nicht „nebenbei“: Legacy-LAPS und Windows-LAPS dürfen sich nicht gleichzeitig um dasselbe Konto kümmern. Der saubere Weg: Windows-LAPS-Richtlinie zuerst an eine Pilotgruppe, dort die Legacy-Konfiguration entfernen, die Geräte verarbeiten lassen und den ersten Abruf über den neuen Weg verifizieren. Beim ersten Verarbeitungslauf rotiert Windows LAPS das Passwort neu – ein bewusster Bruch, kein Problem, sofern der Helpdesk darüber Bescheid weiß.
Rollout als Pilot, nicht als Big Bang
Die Technik ist simpel, die Auswirkungen betreffen aber jeden Support-Prozess, der bisher lokale Admin-Rechte genutzt hat. Fahre die Pilotgruppe ein paar Tage, lass den Helpdesk den Abruf-Workflow einmal real durchspielen, dokumentiere den Ablauf in einem Runbook – und rolle dann über Ringe aus. Der Aufwand für die Pilotphase liegt unter einer Stunde; ein Support-Ausfall wegen „Passwort geht plötzlich nicht mehr“ kostet mehr als das.
Troubleshooting
Erster Blick: das LAPS-Betriebsprotokoll
Fast jedes LAPS-Problem offenbart sich im Ereignisprotokoll des Geräts. Das Protokoll „Microsoft-Windows-LAPS/Operational“ ist die primäre Diagnosequelle – mit klaren Einträgen für erhaltene Richtlinien, durchgeführte Rotationen und fehlgeschlagene Backups:
Die fünf häufigsten Fehlerbilder
Bild 1 – Im Intune-Portal wird kein Passwort angezeigt („Kein Kennwort gefunden“). Ursachen: Die Richtlinie ist noch nicht auf dem Gerät angekommen, die Verarbeitung ist noch nicht gelaufen, oder das Gerät hat sein Passwort noch nie erfolgreich nach Entra gesichert. Prüffolge: Richtlinienstatus im Gerätestatus prüfen, lokal Invoke-LapsPolicyProcessing ausführen, Betriebsprotokoll auf Backup-Fehler kontrollieren, danach die Gerätesynchronisierung erzwingen.
Bild 2 – Backup nach Entra schlägt fehl (Fehlerereignisse im Protokoll). Die klassischen Ursachen: Das Gerät ist nicht oder nicht korrekt Entra-verbunden – dsregcmd /status zeigt den Zustand – oder ein Netzwerk- beziehungsweise Proxyproblem blockiert die Endpunkte. In Hybrid-Umgebungen kommt ein Klassiker dazu: doppelte Entra-Geräteobjekte. Der Backup hängt dann am „Geisterobjekt“ einer alten Anmeldung, und im Portal siehst du am aktiven Gerät nichts. Objekte aufräumen zahlt sich hier doppelt aus.
Bild 3 – AD-Modus: „insufficient access rights“ beim Backup. Das Computerobjekt darf seine eigenen msLAPS-*-Attribute nicht schreiben. Ursache: Die Berechtigungs-Cmdlets wurden nie ausgeführt, oder die Geräte liegen in einer anderen OU als der berechtigten. Lösung: Schritte 2 und 3 aus der AD-Implementierung für die betroffene OU nachziehen, danach den Verarbeitungslauf am Gerät erzwingen.
Bild 4 – Rotation trotz Remote-Aktion ohne Wirkung. Die Aktion „Kennwort des lokalen Administrators rotieren“ ist ein Auftrag, der beim nächsten Kontakt ausgeführt wird. Bei einem Gerät im Standby oder ohne Netzwerk passiert genau: nichts, bis es wieder erreichbar ist. Prüfe den Synchronisierungsstatus des Geräts; im Zweifel arbeitest du am Gerät direkt mit Reset-LapsPassword.
Bild 5 – Falsches Konto wird verwaltet. Typische Varianten: Der im Administrator Account Name angegebene Account existiert auf dem Gerät nicht, weil das Anlage-Skript noch nicht gelaufen ist – LAPS verweigert dann die Verarbeitung. Oder der eingebauten Administrator ist deaktiviert, und es hat niemand bemerkt, weil sich nie jemand damit angemeldet hat. Beides hinterlässt eindeutige Einträge im Betriebsprotokoll.
Und ein Fehlerbild, das oft fälschlich als Bug gemeldet wird: GPO und Intune-Richtlinie konfigurieren LAPS parallel am selben Gerät. Die Engine verarbeitet beide Quellen, und je nach Kombination ist das Ergebnis nicht das, was die einzelne Quelle verspricht. Die Regel lautet: eine Richtlinienquelle pro Gerät. In Co-Management-Szenarien heißt das meist: LAPS gehört eindeutig einer Workload zu – hier Intune.
Fazit
LAPS ist eines der seltenen Beispiele für ein Sicherheitsfeature mit unschlagbarem Kosten-Nutzen-Verhältnis: keine Lizenzkosten für das Feature, kein Agent, ein einziges Konfigurationsprofil in Intune – und damit eliminiert es eines der ältesten und am häufigsten ausgenutzten Probleme der Client-Verwaltung. Die eigentliche Arbeit liegt nicht in der Technik, sondern im Betrieb: Berechtigungen sauber schneiden, Abrufe überwachen, Support-Prozesse anpassen und LAPS als einen Baustein in eine Verteidigungskette aus Credential Guard und ASR-Regeln einbetten.
Wer die Flotte dauerhaft im Blick behalten will, geht einen Schritt weiter: Ein zentraler Report, der für jedes Gerät den Zustand des LAPS-Backups prüft – hat das Gerät ein Passwort gesichert, wie alt ist es, wann rotiert es als Nächstes –, verwandelt die einmalige Einführung in einen kontinuierlich überwachten Zustand. Solche Prüfungen über die gesamte Geräteflotte hinweg lassen sich mit PilotDeploy als automatisierte Reports und Alerts abbilden. Damit ist die lokale Admin-Ebene nicht nur zufällig, sondern nachweisbar sicher – und der klassische Angriffspfad für Lateral Movement verschwindet aus deiner Bedrohungsmatrix.