Reversible Speicherung von AD-Kennwörtern deaktivieren

Ausgangslage: „Disabled“ bedeutet noch nicht bereinigt

Active Directory speichert normale Domänenkennwörter nicht im Klartext. Für NTLM und Kerberos werden Einwegwerte beziehungsweise daraus abgeleitete Schlüssel vorgehalten. Die Einstellung „Kennwörter mit umkehrbarer Verschlüsselung speichern“ durchbricht dieses Modell: Bei der nächsten Kennwortänderung kann AD zusätzlich eine Darstellung ablegen, aus der sich das ursprüngliche Kennwort wiederherstellen lässt. Der Begriff „Verschlüsselung“ klingt dabei stärker, als die Sicherheitswirkung ist. Für die Risikobetrachtung handelt es sich um ein Klartext-Äquivalent.

In gewachsenen Domänen ist die Funktion selten bewusst als strategischer Standard gesetzt. Häufiger stammt sie aus einer alten Einwahl-, RADIUS-, VPN- oder Webanwendung, die klassisches CHAP oder einen anderen Zugriff auf das ursprüngliche Kennwort verlangt hat. Jahre später ist die Anwendung außer Betrieb, der Policy-Wert wieder deaktiviert – aber einzelne Benutzeroptionen, Fine-Grained Password Policies oder bereits gespeicherte reversible Kennwortdarstellungen sind geblieben.

Genau hier entstehen falsche Entwarnungen:

• Die Default Domain Password Policy steht auf Disabled, ein wirksames Password Settings Object (PSO) aber weiterhin auf Enabled.
• Eine Benutzeroption setzt unabhängig davon das Flag ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED beziehungsweise Bit 0x80 in userAccountControl.
• Ein PSO mit Disabled wird als Ausnahme verstanden, obwohl eine domainweite Aktivierung dadurch nicht aufgehoben wird.
• Der Schalter wurde deaktiviert, das Kennwort des betroffenen Kontos danach aber nie geändert.
• Ein Konto erhielt nur „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“; bis zu dieser Anmeldung bleibt der alte Stand bestehen.
• Servicekonten mit Password never expires wurden bei der Bereinigung ausgelassen.
• System-State-Backups enthalten weiterhin den früheren Verzeichnisstand.

Für ein Benutzerkonto entsteht die reversible Speicherung praktisch durch eine ODER-Verknüpfung:

Default-Domain-Policy aktiviert
ODER wirksame Fine-Grained Password Policy aktiviert
ODER per-user Flag 0x80 gesetzt
= reversible Speicherung bei der nächsten Kennwortänderung aktiviert

Alle drei Pfade müssen geschlossen sein, bevor ein neues Kennwort gesetzt wird. Erst diese Reihenfolge verhindert, dass die Rotation den problematischen Wert erneut erzeugt.

Diese Maßnahme ist nicht mit der optionalen Verschlüsselung von Windows-LAPS-Kennwörtern in AD zu verwechseln. LAPS schützt ein bewusst im Verzeichnis hinterlegtes, zufälliges lokales Administratorkennwort über einen eigenen Zugriffspfad. Die hier behandelte Einstellung betrifft Domänenkennwörter von Benutzer- und Dienstkonten.

Zielbild: Drei Schalter aus, danach jedes betroffene Kennwort neu

Ein belastbarer Zielzustand besteht aus Policy, Migration und Nachweis:

1. Die Default Domain Password Policy ist deaktiviert. Der wirksame Wert wird pro Domäne geprüft und über den definierten Policy-Prozess verwaltet.
2. Kein wirksames PSO aktiviert reversible Speicherung. Nicht nur AppliesTo, sondern das resultierende PSO der betroffenen Benutzer wird bewertet.
3. Kein Benutzerkonto trägt das per-user Flag. Ausnahmen sind nicht dauerhaft zugelassen; ein Legacy-Bedarf wird als Migrationsproblem geführt.
4. Klassisches CHAP und verifizierte klartextabhängige Legacy-Pfade sind entfernt oder nachweislich ersetzt. Der Protokollname allein reicht nicht als Begründung. Insbesondere sind PEAP-MS-CHAPv2 und modernes IIS Advanced Digest nicht pauschal als Abhängigkeit von reversibler Kennwortspeicherung zu bewerten.
5. Alle möglicherweise betroffenen Kennwörter wurden erst nach der vollständigen Deaktivierung geändert. PasswordLastSet liegt nach einem dokumentierten Härtungsstichtag.
6. Technische Konten besitzen einen eigenen Rotationsplan. Secrets werden mit Workload-Ownern aktualisiert; geeignete Dienste wechseln auf gMSA oder einen vergleichbaren verwalteten Identitätspfad.
7. Alte Backups bleiben bis zum Ende ihrer Aufbewahrung besonders geschützt. Der aktuelle AD-Zustand bereinigt keine historischen Sicherungen.
8. Änderungen werden überwacht. Domain Policy, PSOs und das relevante Benutzerflag dürfen nicht still wieder aktiviert werden.

Das Ziel ist nicht nur ein grüner Policy-Report. Es ist eine belegbare Kette aus deaktivierten Aktivierungspfaden, migrierten Abhängigkeiten und danach erneuerten Kennwörtern.

Umsetzung: Von der Inventur zur belegbaren Bereinigung

1) Domain Policy, PSOs und Benutzerflag getrennt erfassen

Die Inventur gehört auf einen administrativ geschützten Managementhost mit dem ActiveDirectory-Modul. Sie liest keine Kennwörter und greift nicht auf interne Credential-Attribute zu. Die folgenden Abfragen liefern die drei relevanten Konfigurationsebenen als Objekte:

& {
  Set-StrictMode -Version Latest
  Import-Module ActiveDirectory -ErrorAction Stop

  $domain = Get-ADDomain -ErrorAction Stop
  $defaultPolicy = Get-ADDefaultDomainPasswordPolicy `
    -Identity $domain.DNSRoot `
    -ErrorAction Stop

  [pscustomobject]@{
    Scope                         = $domain.DNSRoot
    PolicyType                    = 'DefaultDomainPasswordPolicy'
    ReversibleEncryptionEnabled  = $defaultPolicy.ReversibleEncryptionEnabled
  }

  Get-ADFineGrainedPasswordPolicy -Filter * -ErrorAction Stop |
    Select-Object Name, Precedence, ReversibleEncryptionEnabled, AppliesTo

  Get-ADUser `
    -LDAPFilter '(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=128))' `
    -Properties Enabled, PasswordLastSet, PasswordNeverExpires, userAccountControl `
    -ErrorAction Stop |
    Select-Object SamAccountName, Enabled, PasswordLastSet, PasswordNeverExpires,
      @{Name='PerUserReversibleEncryption';Expression={($_.userAccountControl -band 0x80) -ne 0}}
}

Die Ausgabe enthält sicherheitsrelevante Kontonamen und gehört deshalb nicht in ein offenes Ticket oder ungeschütztes Share. Sie zeigt außerdem nur den aktuellen Konfigurationsstand. Ob ein Konto in der Vergangenheit bereits eine reversible Darstellung erhalten hat, lässt sich daraus nicht zuverlässig ableiten.

Für Benutzer, auf die mehrere PSOs direkt oder über Gruppen wirken, zählt nur das resultierende PSO. Direkt zugewiesene PSOs haben Vorrang vor gruppenbasierten; bei gleicher Zuweisungsebene gewinnt die niedrigste Precedence. Für repräsentative und potenziell betroffene Konten muss deshalb der effektive Wert geprüft werden:

Get-ADUserResultantPasswordPolicy -Identity 'pilot.user' -ErrorAction Stop |
  Select-Object Name, Precedence, ReversibleEncryptionEnabled

Liefert der Befehl kein PSO, gilt für dieses Konto die Default Domain Password Policy. In großen Domänen sollte die Auswertung kontrolliert und gedrosselt erfolgen, nicht als unlimitierte Parallelabfrage gegen einen Domain Controller.

2) Den historischen Geltungsbereich konservativ bestimmen

Ein aktuelles Disabled beweist nicht, wann die Einstellung deaktiviert wurde. Für den Rotationsumfang werden deshalb mehrere Spuren zusammengeführt:

• GPO-Backups, Change-Tickets und Policy-Analyzer-Exporte,
• Änderungszeitpunkte und Versionen der Password Settings Objects,
• Benutzeränderungen am Flag 0x80, soweit die Audit-Historie reicht,
• PasswordLastSet, Kontoalter und bekannte Service-Migrationen,
• System- und Anwendungseigentümer der früheren Legacy-Authentifizierungspfade.

Ist der Aktivierungszeitraum unbekannt, ist die sichere Annahme größer als die sichtbare Treffermenge: Alle Konten, deren Kennwort während des möglichen Zeitraums unter einer aktivierenden Domain Policy, einem aktivierenden PSO oder einem gesetzten per-user Flag 0x80 geändert worden sein könnte, gehören in den Rotationsplan. Eine LDAP-Abfrage nach dem heutigen Benutzerflag reicht dafür nicht.

Deaktivierte Konten werden nicht pauschal ignoriert. Noch benötigte Konten erhalten nach der Policy-Bereinigung ein neues zufälliges Kennwort. Nicht mehr benötigte Konten werden nach dem vorhandenen Stilllegungsprozess entfernt oder dauerhaft unbrauchbar gemacht. Eingebaute Identitäten, Trust-Konten und krbtgt gehören nicht in eine generische Massenrotation, sondern in ihre jeweiligen Runbooks.

3) Klassisches CHAP und verifizierte Legacy-Abhängigkeiten zuerst ersetzen

Vor jeder Änderung muss klar sein, welcher Workload tatsächlich das ursprüngliche Kennwort benötigt. Typische Prüfstellen sind:

• NPS-, RAS-, VPN- und WLAN-Richtlinien mit klassischem CHAP,
• IIS-Sites und Anwendungen mit Digest Authentication, deren Version und konkrete Credential-Nutzung getrennt geprüft werden,
• ältere Appliances, Middleware oder Fachanwendungen mit proprietärer Kennwortprüfung,
• technische Konten, die nur wegen einer historischen Herstelleranforderung das per-user Flag tragen.

Ein Produktname oder ein altes Architekturdiagramm ist kein ausreichender Nachweis. Entscheidend sind die wirksame Authentifizierungsmethode, ein reproduzierbarer Test und ein verantwortlicher Owner. Bei IIS muss zusätzlich differenziert werden: Ältere Digest-Implementierungen konnten ein wiederherstellbares Kennwort benötigen, modernes Advanced Digest arbeitet dagegen mit vorberechneten Digest-Credentials. Digest bleibt ein gesondert zu modernisierender Legacy-Pfad, sein bloßes Vorhandensein beweist aber keine reversible Kennwortspeicherung. Moderne Zielpfade können je nach Anwendung zertifikatsbasierte EAP-Verfahren, Kerberos/Negotiate, ein vorgelagertes modernes Authentifizierungssystem oder eine aktualisierte Produktversion sein.

Falls eine Abhängigkeit nicht sofort abgelöst werden kann, bleibt die Ausnahme auf ein dediziertes, nicht privilegiertes Konto begrenzt. Das Konto erhält nur die notwendigen Logon-Rechte und Netzwerkpfade, ein langes einzigartiges Kennwort, Monitoring sowie einen verbindlichen Owner und ein Ablaufdatum. Eine einzelne Altanwendung rechtfertigt keine erneute domainweite Aktivierung.

4) Aktivierungspfade in der richtigen Reihenfolge schließen

Die Default-Domain-Einstellung wird verbindlich über den kontrollierten Gruppenrichtlinienprozess auf Domänenebene verwaltet:

Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Kontorichtlinien > Kennwortrichtlinien > Kennwörter mit umkehrbarer Verschlüsselung speichern = Deaktiviert

Eine Kopie in einer Workstation- oder Benutzer-OU ändert die Domänenkennwortrichtlinie nicht. Die autoritative, höchstpriorisierte GPO am Domain Root wird zuerst aktualisiert und auf Konflikte geprüft. Set-ADDefaultDomainPasswordPolicy ändert den wirksamen Verzeichniswert, schreibt aber keine GPO-Definition; eine widersprechende GPO kann den Wert erneut setzen. Der Cmdlet-Schritt eignet sich deshalb nur als kontrollierte Sofortmaßnahme innerhalb desselben Runbooks und wird zunächst mit -WhatIf geprüft:

$domain = Get-ADDomain -ErrorAction Stop

Set-ADDefaultDomainPasswordPolicy `
  -Identity $domain.DNSRoot `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

Aktivierende PSOs werden nach bestätigter Abhängigkeitsmigration einzeln geändert. Auch hier dient -WhatIf zuerst der Scope-Prüfung:

Set-ADFineGrainedPasswordPolicy `
  -Identity 'Legacy-CHAP-Users' `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

Beim Benutzerflag darf userAccountControl nicht als komplette Zahl überschrieben werden, weil dabei andere Account-Flags verloren gehen können. Der gezielte Cmdlet-Parameter verändert nur die gewünschte Option:

Set-ADAccountControl `
  -Identity 'legacy.service' `
  -AllowReversiblePasswordEncryption $false `
  -WhatIf

Nach Freigabe werden dieselben Änderungen ohne -WhatIf ausgeführt. Domain Policy, PSOs und Änderungen an Benutzerflags werden in getrennten Changes behandelt, damit Ursache und Wirkung nachvollziehbar bleiben. Danach müssen AD-Replikation und effektive Werte gegen mehrere Domain Controller geprüft werden, bevor die erste Kennwortrotation beginnt.

5) Kennwörter erst nach vollständiger Deaktivierung rotieren

Das Abschalten wirkt nur für künftige Kennwortänderungen. Bereits gespeicherte reversible Darstellungen bleiben bestehen, bis das jeweilige Kennwort tatsächlich geändert wird. Die Rotation ist deshalb der sicherheitswirksame Teil der Bereinigung.

Die Reihenfolge sollte nach Risiko und Betriebsart getrennt werden:

1. privilegierte personenbezogene Konten und administrative Break-Glass-Konten nach eigenem Verfahren,
2. normale Benutzer in unterstützten Wellen mit klarer Helpdesk-Kommunikation,
3. Servicekonten gemeinsam mit Anwendung, Secret Store, Scheduled Tasks, Diensten und Abhängigkeiten,
4. deaktivierte, aber aufzubewahrende Konten mit zufälligem neuen Secret,
5. Sonderidentitäten nur über produktspezifische Runbooks.

Bei Servicekonten ist „Kennwort bei nächster Anmeldung ändern“ ungeeignet. Das Secret wird kontrolliert erzeugt, im vorgesehenen Vault hinterlegt, am Workload aktualisiert und anschließend funktional getestet. Wo die Anwendung es unterstützt, reduziert eine Migration auf gMSA den künftigen manuellen Rotationsaufwand.

Ein Legacy-Test direkt nach dem Policy-Change kann täuschen: Solange das alte reversible Material vorhanden ist, funktioniert die bisherige Anmeldung möglicherweise weiterhin. Der Canary-Test ist erst nach einer neuen Kennwortsetzung aussagekräftig.

6) Abschluss über Stichtag und Rotation nachweisen

Für jede Domäne wird ein Härtungsstichtag dokumentiert, an dem alle drei Aktivierungspfade nach Replikationskonvergenz nachweislich deaktiviert waren. Für jedes Konto im Scope gilt anschließend:

PasswordLastSet > Härtungsstichtag

Der Nachweis umfasst mindestens:

• effektive Default Domain Password Policy pro Domäne,
• alle PSOs mit Precedence, Zuweisung und aktuellem Reversible-Encryption-Wert,
• vollständige Treffermenge des per-user Flags 0x80, idealerweise leer,
• Rotationsstatus, Owner und Funktionstest je Kontoklasse,
• dokumentierte Rest-Ausnahmen mit Ablaufdatum und Kompensationskontrollen,
• Replikations- und GPO-Status nach dem Change,
• Monitoring auf erneute Änderungen.

Die Events 4738 und 4739 können Änderungen an Benutzer- beziehungsweise Domänenrichtlinien sichtbar machen. Mit geeigneter Directory-Service-Change-Auditierung und SACLs ergänzt Event 5136 Änderungen an relevanten AD-Objekten. Entscheidend ist nicht eine einzelne Event-ID, sondern dass Änderungen am Benutzerflag, an Domain-Policy-Eigenschaften und an PSOs zentral erfasst und einem autorisierten Change zugeordnet werden.

Historische System-State- und DC-Backups lassen sich durch den Live-Change nicht rückwirkend bereinigen. Sie bleiben bis zum Retention-Ende hochsensibel, benötigen restriktiven Zugriff und einen getesteten Restore-Prozess. Nach einer Wiederherstellung aus einem alten Stand müssen die Härtung erneut geprüft und betroffene Kennwörter wieder rotiert werden.

Vorteile: Weniger wiederherstellbares Kennwortmaterial, klarer Nachweis

• Wiederherstellbare Kennwortdarstellungen werden entfernt. Nach der anschließenden Rotation enthält der aktuelle AD-Stand für die betroffenen Konten kein durch diese Funktion erzeugtes Klartext-Äquivalent mehr.
• Der Change ist technisch klar messbar. Drei Konfigurationspfade und ein Rotationsstichtag ergeben einen nachvollziehbaren Nachweis.
• Legacy-Abhängigkeiten werden sichtbar. Veraltete CHAP- und verifizierte klartextabhängige Pfade erhalten Owner, Migrationsplan und Ablaufdatum statt einer unsichtbaren Domain-Ausnahme.
• Die Auswirkung eines AD- oder Backup-Abflusses sinkt. Ein wiederherstellbares Kennwort ist besonders kritisch, wenn es entgegen der Vorgaben auch außerhalb der Domäne verwendet wurde.
• Der Betrieb wird einfacher. Eine domainweite Sonderkonfiguration entfällt; Ausnahmen werden auf konkrete Workloads und Konten begrenzt.

Nachteile und Grenzen: Die Rotation ist der eigentliche Aufwand

• Legacy-Authentifizierung kann ausfallen. Klassisches CHAP und andere bestätigte klartextabhängige Pfade müssen vor der Rotation migriert oder gezielt isoliert werden; IIS Digest benötigt unabhängig davon einen versions- und konfigurationsbezogenen Kompatibilitätstest.
• Servicekonten verursachen Koordinationsaufwand. Ein ungeplanter Reset kann Dienste, Jobs, Appliances oder Schnittstellen unterbrechen.
• Der aktuelle Policy-Stand beweist keine historische Bereinigung. Ohne belastbare Historie ist ein konservativer Rotationsumfang erforderlich.
• Backups behalten frühere Secrets. Die Maßnahme ändert keine alten System-State-Sicherungen und keine exportierten Verzeichnisstände.
• NT-Hashes und Kerberos-Schlüssel bleiben Teil von AD. Die Kontrolle ersetzt weder DC-Härtung, Schutz von Replikationsrechten, starke Kennwörter, privilegierte Adminpfade noch MFA an geeigneten Zugängen.
• Hybride Identitäten brauchen eine eigene Betrachtung. Der AD-DS-Change ändert nicht automatisch Kennwortmaterial oder Authentifizierungspfade in reinen Cloud-Systemen.
• Das Ergebnis ist nicht direkt per LDAP beweisbar. Normale Inventurabfragen zeigen die Aktivierungspfade, aber nicht sicher den historischen Inhalt interner Credential-Strukturen. Policy-Zustand und Rotation nach Stichtag bilden deshalb den belastbaren Betriebsnachweis.

Typische Stolperfallen

• Nur die Default Domain Policy prüfen und aktivierende PSOs oder das per-user Flag übersehen.
• Annehmen, ein PSO mit Disabled überschreibe eine domainweite Aktivierung.
• PSO-Zuweisungen aus AppliesTo ableiten, ohne die resultierende Policy des Benutzers zu prüfen.
• Die Policy deaktivieren, aber Kennwörter nicht danach ändern.
• „Kennwort bei nächster Anmeldung ändern“ als bereits abgeschlossene Rotation zählen.
• Sofort nach dem Policy-Change testen und wegen des alten Kennwortmaterials einen falschen Migrationserfolg annehmen.
• userAccountControl numerisch überschreiben und dabei andere Account-Eigenschaften beschädigen.
• Servicekonten ohne Owner, Abhängigkeitsmatrix, Vault-Update und Rollback rotieren.
• PEAP-MS-CHAPv2 allein wegen des Namens als Beleg für reversible Speicherung behandeln.
• IIS Digest pauschal als Klartextabhängigkeit behandeln, ohne Version und Credential-Pfad zu prüfen.
• Für eine einzelne Altanwendung den Domain-Wert wieder aktivieren.
• Deaktivierte Konten und Password never expires aus dem Scope nehmen.
• Den aktuellen DC prüfen, aber Replikationskonvergenz, andere Domänen und alte Backups ignorieren.
• LAPS-Kennwortverschlüsselung mit der hier behandelten Domain-Kennwortoption verwechseln.

Projekt-Checkliste

• [ ] Effektive Default Domain Password Policy für jede Domäne erfassen.
• [ ] Alle Fine-Grained Password Policies mit Status, Precedence und Zuweisungen exportieren.
• [ ] Resultierendes PSO für potenziell betroffene und repräsentative Benutzer bestimmen.
• [ ] Alle Benutzerkonten mit userAccountControl-Bit 0x80 inventarisieren.
• [ ] Historischen Aktivierungszeitraum aus GPO-Backups, Changes und Auditdaten rekonstruieren.
• [ ] Unklare historische Scopes konservativ in den Rotationsumfang aufnehmen.
• [ ] Klassisches CHAP und andere klartextabhängige Drittprodukt-Pfade technisch verifizieren.
• [ ] IIS Digest separat nach Version, Konfiguration und Credential-Pfad bewerten.
• [ ] Für jede Abhängigkeit Owner, Zielprotokoll, Testfall und Abschaltdatum festlegen.
• [ ] Canary-Konten und funktionale Tests für jeden Authentifizierungspfad vorbereiten.
• [ ] Die Einstellung in der autoritativen wirksamen Domain-Root-GPO deaktivieren und den effektiven Verzeichniswert prüfen.
• [ ] Aktivierende PSOs und per-user Flags in kontrollierten Changes deaktivieren.
• [ ] Effektiven Zustand und Replikation gegen mehrere Domain Controller prüfen.
• [ ] Härtungsstichtag erst nach vollständiger Konvergenz festhalten.
• [ ] Privilegierte Konten nach ihrem dedizierten Runbook rotieren.
• [ ] Normale Benutzer in unterstützten Wellen zur tatsächlichen Kennwortänderung bringen.
• [ ] Servicekonten mit Workload-Owner, Vault-Update, Funktionstest und Rollback rotieren.
• [ ] Geeignete Servicekonten auf gMSA oder einen verwalteten Identitätspfad migrieren.
• [ ] Deaktivierte, aber aufzubewahrende Konten sicher behandeln.
• [ ] Für jedes Konto PasswordLastSet nach dem Härtungsstichtag nachweisen.
• [ ] Legacy-Canary-Tests erst nach der Kennwortänderung durchführen.
• [ ] Änderungen an Domain Policy, PSOs und Benutzerflag zentral überwachen.
• [ ] Alte System-State-Backups bis zum Retention-Ende restriktiv schützen.
• [ ] Rest-Ausnahmen mit Owner, Scope, Kompensationskontrollen und Ablaufdatum dokumentieren.
• [ ] Wiederkehrende Compliance-Prüfung für alle drei Aktivierungspfade einrichten.