LAPS rotiert, aber der Helpdesk darf zu viel

Die Kennwörter lokaler Administratorkonten wechseln zuverlässig. Trotzdem kann eine historisch gewachsene Supportgruppe auf deutlich mehr Geräte zugreifen, als ihr Aufgabenbereich erfordert. Oder die neu delegierte Gruppe liest das LAPS-Attribut, erhält aber kein verwendbares Kennwort. Beides entsteht, wenn LAPS als reine Rotationsfunktion eingeführt wird.

Dieser Beitrag behandelt den Passwortzugriff bei Windows LAPS mit Sicherung nach AD DS. Der allgemeine Rollout ist bereits erfolgt; jetzt werden Berechtigungen, Verschlüsselung und Nachweisführung überprüft. Microsoft-Entra-Rollen und die alte Microsoft-LAPS-Lösung haben andere Zugriffspfade und gehören in getrennte Prüfungen.

Drei Fähigkeiten getrennt vergeben

Das Zielbild unterscheidet, wer Kennwortattribute lesen, verschlüsselte Kennwörter entschlüsseln und den Ablaufzeitpunkt verändern darf. Leserechte werden über AD-ACLs gesteuert. Bei verschlüsselter Speicherung kommt ein autorisierter Entschlüsselungsprincipal hinzu. Das Recht, einen früheren Ablauf anzufordern, gewährt keinen Passwortabruf und ersetzt keine erfolgreiche Rotation am Gerät.

Definieren Sie dafür Gerätebereiche und verantwortliche Gruppen: beispielsweise Standardclients, besonders sensible Arbeitsplätze und Mitgliedsserver. Tier-0-Systeme bleiben getrennt. Für jede Gruppe müssen fachlicher Eigentümer, zulässige Geräte und Freigabeverfahren feststehen. Prüfen Sie auch, wer ihre Mitgliedschaft verändern darf; diese Delegation gehört zum Passwortzugriff.

Die beiden Zugriffsebenen ergeben keine automatische Vier-Augen-Freigabe. Wer beide Voraussetzungen erfüllt, kann das Kennwort abrufen. Ein Genehmigungsprozess benötigt eine eigene technische oder organisatorische Umsetzung.

Vorhandene Rechte ohne Kennwortabruf inventarisieren

Starten Sie auf einer administrativen Arbeitsstation mit den Modulen ActiveDirectory und LAPS. Verwenden Sie ein Konto mit den erforderlichen Leserechten. Das Beispiel liest ausschließlich Domäneninformationen und Berechtigungen; es ruft keine Kennwörter ab. Ersetzen Sie Beispiel-OU und DC durch den freigegebenen Pilotbereich.

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
Import-Module ActiveDirectory
Import-Module LAPS

$pilotOu = 'OU=LAPS-Pilot,OU=Clients,DC=example,DC=com'
$dc = 'dc01.example.com'

Get-ADDomain -Server $dc |
    Select-Object DNSRoot, DomainMode

Find-LapsADExtendedRights -Identity $pilotOu `
    -DomainController $dc -IncludeComputers |
    Select-Object ObjectDN, ExtendedRightHolders

-IncludeComputers bezieht Computerobjekte in die Prüfung ein. Die Ergebnisse sind ein Einstieg, kein vollständiger Nachweis effektiver Berechtigungen. Prüfen Sie zusätzlich Gruppenverschachtelungen, explizite ACEs, unterbrochene Vererbung sowie Rechte zur Änderung von ACLs und Gruppen. Breite Extended Rights und Vollzugriff verdienen besondere Aufmerksamkeit.

Dokumentieren Sie jeden unerwarteten Berechtigten mit Herkunft, Eigentümer und Entscheidung. Entfernen Sie keine ACEs pauschal: Andere delegierte Aufgaben können davon abhängen. Die Bereinigung braucht gesicherte Ausgangs-ACLs, einen begrenzten Change und anschließende Funktionstests.

Leserechte im Pilotbereich delegieren

Vergeben Sie Rechte an verwaltete Sicherheitsgruppen und an der vorgesehenen OU, nicht vorsorglich an der Domänenwurzel. Eine Vorschau für genau einen Bereich sieht so aus:

Set-LapsADReadPasswordPermission `
    -Identity 'OU=LAPS-Pilot,OU=Clients,DC=example,DC=com' `
    -AllowedPrincipals 'EXAMPLE\LAPS-Client-Recovery' `
    -WhatIf

-WhatIf ändert nichts und beweist noch keinen funktionierenden Zugriff. Prüfen Sie Gruppe, Ziel und Vererbungsumfang; führen Sie die Änderung anschließend im freigegebenen Change ohne -WhatIf und mit -Confirm aus. Kontrollieren Sie danach erneut die ACLs. Der Befehl ist keine Bereinigung bisheriger Delegationen: Vorhandene überbreite Rechte müssen separat bewertet werden.

Eine Gruppe, die lediglich Rotation anfordern soll, erhält gezielt die entsprechende Delegation über Set-LapsADResetPasswordPermission. Das Setzen eines Ablaufzeitpunkts ändert nicht sofort das lokale Kennwort. Erst die Verarbeitung durch das erreichbare Gerät und die erfolgreiche Sicherung schließen den Vorgang ab.

Entschlüsselung auf denselben Gerätebereich begrenzen

Verschlüsselte Speicherung setzt mindestens die Domänenfunktionsebene Windows Server 2016 voraus. Unter Computer Configuration > Policies > Administrative Templates > System > LAPS konfigurieren Sie für den Pilotbereich AD DS als Sicherungsziel, aktivierte Passwortverschlüsselung und den vorgesehenen autorisierten Entschlüsseler. Die zugehörigen Einstellungen heißen BackupDirectory, ADPasswordEncryptionEnabled und ADPasswordEncryptionPrincipal.

Windows LAPS verwendet dafür einen einzelnen Benutzer oder eine einzelne Gruppe. Ohne explizit gesetzten Entschlüsselungsprincipal ist dies die Domain-Admins-Gruppe. Nutzen Sie eine dedizierte Sicherheitsgruppe; bei mehreren Rollen kann sie kontrolliert verwaltete Gruppen zusammenfassen. Prüfen Sie die effektiven Mitglieder und deren Zuständigkeit, bevor Geräte damit verschlüsseln.

Ein Wechsel des Principals schreibt bestehende verschlüsselte Kennwörter nicht um. Planen Sie deshalb eine kontrollierte Rotation und erfolgreiche Sicherung unter der neuen Richtlinie. Vorhandene Kennworthistorien bleiben an ihren damaligen Principal gebunden. Entfernte Berechtigte können bereits bekannte Kennwörter weiterhin kennen; auch deshalb gehört Rotation zur Entziehung von Zugriff.

DSRM ist ein Sonderfall: Für die Sicherung auf Domain Controllern gilt die Domain-Admins-Gruppe der jeweiligen Domäne als Entschlüsseler; ein abweichender ADPasswordEncryptionPrincipal wird dort ignoriert. Übertragen Sie das Client-Helpdesk-Modell nicht auf DCs.

Positiv- und Negativtests ohne Klartextprotokoll

Prüfen Sie den Abruf auf einem einzelnen freigegebenen Pilotgerät mit getrennten Testsitzungen: berechtigter Support, nicht berechtigter Benutzer und Support eines anderen Gerätebereichs. Nach Gruppenänderungen müssen die Tests mit erneuertem Anmeldekontext erfolgen.

Get-LapsADPassword -Identity 'LAPS-PILOT-01' `
    -DomainController 'dc01.example.com' -ErrorAction Stop |
    Select-Object ComputerName, Source, DecryptionStatus,
        AuthorizedDecryptor, PasswordUpdateTime

Dieser Aufruf versucht tatsächlich einen Passwortabruf und gegebenenfalls die Entschlüsselung. Er gehört deshalb auf eine vertrauenswürdige Adminstation. Ohne -AsPlainText wird das Kennwort als SecureString zurückgegeben; die Auswahl zeigt nur Prüfmetadaten. Exportieren Sie niemals das vollständige Ergebnis in Tickets oder Protokolle.

Für einen berechtigten Test bei verschlüsselter Speicherung erwarten Sie Source: EncryptedPassword und DecryptionStatus: Success. Gleichen Sie zusätzlich AuthorizedDecryptor mit der freigegebenen Zielgruppe ab und prüfen Sie anhand von PasswordUpdateTime, dass die geplante Rotation erfolgt ist. Für Negativtests darf kein verwendbares Kennwort verfügbar sein. Unterscheiden Sie fehlenden Attributzugriff, verweigerte Entschlüsselung und technische Fehler. Ein defekter DC-Zugriff beweist keine wirksame Zugriffssperre.

Audit bis zum zuständigen DC nachweisen

Konfigurieren Sie die LAPS-bezogenen SACLs mit Set-LapsADAuditing gezielt am Pilotbereich. Definieren Sie dabei sowohl legitime Abrufe als auch die zu beobachtenden unberechtigten Zugriffsversuche. Auf den zuständigen DCs muss die passende Unterkategorie Audit Directory Service Access für die vorgesehenen Erfolgs- und Fehlerfälle aktiviert sein.

Validieren Sie mit den Testkonten die Ereignisse 4662 und deren Weiterleitung. Korrelieren Sie Identität, Objekt, Zugriffstyp und Zeitpunkt. Eine 4662-Meldung über das Lesen eines verschlüsselten Attributs beweist keine erfolgreiche Entschlüsselung. Eine erst danach verweigerte Entschlüsselung muss auch nicht als fehlgeschlagener AD-Lesezugriff erscheinen.

Definieren Sie konkrete Alarme: viele Geräteabrufe in kurzer Zeit, Zugriff außerhalb des zuständigen Bereichs und Änderungen an Berechtigungsgruppen. Kennwortwerte gehören weder ins SIEM noch in Supporttickets.

Vorteile der getrennten Zugriffskontrollen

  • Supportrechte lassen sich auf tatsächlich betreute Geräte begrenzen.
  • Verschlüsselung schafft eine zusätzliche Kontrolle neben der AD-ACL.
  • Rotation kann delegiert werden, ohne zugleich Passwortabruf zu erlauben.
  • Wiederholbare Zugriffstests zeigen, ob das Rollenmodell nach OU- oder Gruppenänderungen noch funktioniert.

Nachteile und Grenzen im Betrieb

  • Zwei Zugriffsebenen erhöhen Diagnose- und Pflegeaufwand; ein falsch gewählter Entschlüsseler kann Recovery blockieren.
  • Wer bereits Kennwörter kennt, verliert dieses Wissen nicht durch eine Gruppenänderung.
  • LAPS ersetzt weder geschützte Adminarbeitsplätze noch sichere Gruppen- und GPO-Verwaltung. Gegen kompromittierte Domänenadministration bildet es keine unabhängige Sicherheitsgrenze.
  • Ein AD-basierter Abrufweg ist bei einem umfassenden Verzeichnisausfall möglicherweise nicht verfügbar. Der Notfallprozess muss diese Abhängigkeit ausdrücklich behandeln.

Typische Stolperfallen vor der Abnahme

Eine saubere OU-Delegation hilft wenig, wenn darüber eine alte Supportgruppe Vollzugriff erbt. Ebenso kritisch sind Geräteverschiebungen ohne neue Zugriffsprüfung, veraltete Anmeldetoken in Negativtests und die Verwechslung von AD-Leseaudit mit Passwortnutzung. Ein weiterer Fehler ist die Annahme, eine erfolgreiche Metadatenabfrage beweise bereits einen funktionierenden lokalen Notfall-Login.

Üben Sie diesen Login separat an einem isolierten Pilotgerät mit kontrollierter Kennwortanzeige, ohne Aufzeichnung des Geheimnisses. Prüfen Sie danach Rotation und erneute Sicherung. Für Ausfälle von AD oder des üblichen Adminarbeitsplatzes ist ein gesondert geschützter und geübter Wiederherstellungsweg erforderlich; pauschale Passwortexporte sind dafür kein Betriebsmodell.

Projekt-Checkliste für die Freigabe

  • [ ] Gerätebereiche, Gruppenverantwortliche und Änderungsrechte dokumentiert.
  • [ ] OU- und Objektberechtigungen einschließlich Vererbung geprüft.
  • [ ] Leserecht, Entschlüsseler und Rotationsdelegation getrennt festgelegt.
  • [ ] Richtlinienwirkung, Rotation und Sicherung am Pilotgerät nachgewiesen.
  • [ ] Berechtigter Abruf sowie bereichsfremder und unberechtigter Zugriff getestet.
  • [ ] Kennworthistorien und bisherige Berechtigte beim Wechsel berücksichtigt.
  • [ ] DC-Audit, Ereignisweiterleitung und Alarme praktisch validiert.
  • [ ] Notfallanmeldung, anschließende Rotation und AD-Ausfallszenario geübt.
  • [ ] Wiederholungsprüfung nach OU-, Gruppen- und GPO-Änderungen vereinbart.