AD Benutzer kann Passwort nicht wechseln: Deny-ACEs

AD Benutzer kann Passwort nicht wechseln: Was bedeutet die Einstellung?

Bei der Fehlersuche zum Problem AD Benutzer kann Passwort nicht wechseln prüfen Sie die frei definierbare Zugriffskontrollliste (DACL) des Benutzers, bevor Sie die Kennwortrichtlinie der Domäne ändern. Dem Konto kann das erweiterte Recht Change Password verweigert sein. Dies ist eine Zugriffsbeschränkung für Kennwortänderungen durch den Benutzer selbst und eine andere Frage als die, ob ein Administrator das Kennwort zurücksetzen kann.

Beginnen Sie mit dem genauen Konto und dem fehlgeschlagenen Vorgang. Halten Sie fest, ob die Person ihr eigenes Kennwort ändern wollte oder einen Helpdesk-Mitarbeiter gebeten hat, ein neues zu setzen. Eine erfolgreiche administrative Zurücksetzung belegt nicht, dass die eigene Kennwortänderung erlaubt ist. Ebenso lässt sich aus einer fehlgeschlagenen eigenen Änderung allein keine Deny-ACE als Ursache ableiten: Die DACL muss weiterhin gelesen werden.

Dieser Leitfaden untersucht eine bestimmte Berechtigungsbedingung, statt ein neues Kennwortalter oder eine neue Kennwortlänge vorzugeben. Prüfen Sie die übergeordnete Richtlinie getrennt: Kennwortsicherheit in Active Directory behandelt Domänenrichtlinien, Ablauf, Kontoeinstellungen und die Speicherung von Anmeldedaten. Änderungen an diesen Kontrollen ersetzen nicht die Feststellung, welche ACEs für das untersuchte Konto gelten.

Funktionsweise: Eigene Kennwortänderung und administrative Zurücksetzung

Microsoft bezeichnet das erweiterte Recht User-Change-Password mit dem Anzeigenamen Change Password und der GUID ab721a53-1e2f-11d0-9819-00aa0040529b. Die relevanten Nachweise stehen im Sicherheitsdeskriptor des Benutzerobjekts. Leiten Sie den Zustand nicht aus einem gewöhnlichen Bittest für userAccountControl ab: Die hier untersuchte Collector-Bedingung verwendet dieses Attribut nicht.

Das Microsoft-Verfahren zur LDAP-Änderung beschreibt eine Standardkonfiguration mit objektspezifischen ACEs für zwei Berechtigungsträger: Everyone und SELF. Zum Verweigern der Berechtigung dient ADS_ACETYPE_ACCESS_DENIED_OBJECT; zum Gewähren dient der entsprechende objektspezifische Allow-Typ.

Zu erfassendes Element	Wert für diese Prüfung	Bedeutung
Objekttyp	`ab721a53-1e2f-11d0-9819-00aa0040529b`	Kennzeichnet Change Password statt einer anderen Objektberechtigung
Berechtigungsträger Everyone	`S-1-1-0`	Einer der vom Collector-Prädikat akzeptierten Berechtigungsträger
Berechtigungsträger SELF	`S-1-5-10`	Der andere von diesem Prädikat akzeptierte Berechtigungsträger
ACE-Richtung	Deny	Ein Allow-Eintrag erfüllt die Detektorbedingung nicht
Ziel	Exakter Distinguished Name des Benutzers	Ermöglicht die Zuordnung der Nachweise zum richtigen Konto

Bewahren Sie die Unterscheidung zwischen der dokumentierten Konfiguration und der Detektorbedingung. Microsofts Lesebeispiel erkennt den standardmäßigen verweigerten Zustand, wenn beide ACEs der Berechtigungsträger vom Typ Deny sind. Der Collector verwendet eine OR-Bedingung: Eine passende Deny-ACE für einen der beiden Berechtigungsträger genügt seinem Prädikat. Erfassen Sie eine einzelne passende ACE als prüfbedürftigen Zustand mit nur einem Berechtigungsträger; beschreiben Sie ihn nicht als vollständige Konfiguration aus zwei ACEs aus dem Microsoft-Beispiel.

Die administrative Kennwortzurücksetzung ist eine eigenständige Berechtigungsfrage. Der ResetNightmare-Artikel behandelt einen Exploit für einen Kerberos-Kennwortvorgang und die Abgrenzung zu delegierten Reset Password-Rechten. Er liefert Kontext zur Trennung der Vorgänge, keinen Nachweis dafür, dass diese Beschränkung der eigenen Kennwortänderung den Exploit verursacht. Bewerten Sie diese gesonderte Gefährdung anhand der Voraussetzungen und Abhilfemaßnahmen im verlinkten Artikel.

Erkennung: Die DACL unabhängig lesen

Schritt 1: Konto auswählen und Kontext bewahren

Verwenden Sie den Distinguished Name des Kontos statt eines geratenen Anzeigenamens. Notieren Sie Kontoverantwortlichen, aktivierten oder deaktivierten Zustand, Geschäftszweck, abgefragten Domänencontroller und Prüfzeitpunkt. Nehmen Sie deaktivierte Konten in das Inventar auf, wenn Sie es mit diesem Collector-Prädikat abgleichen: Detect() besitzt keinen Disabled-Filter. Der Kontozustand kann die Priorität der Korrektur beeinflussen, darf aber keinen Eintrag stillschweigend aus der Berechtigungsprüfung entfernen.

Klären Sie bei einer Dienstidentität, wer die Kennwortänderungen verantwortet, bevor Sie die Beschränkung als unerwünscht einstufen. Entscheidend ist, ob sie beabsichtigt ist und durch einen Prozess mit klarer Verantwortung gestützt wird. Die Bezeichnung als Dienstkonto allein ist kein ausreichender Nachweis für eine Ausnahme.

Schritt 2: Zugriffsregeln abrufen und filtern

Microsofts LDAP-Leseverfahren liest ntSecurityDescriptor, ruft dessen DACL ab und untersucht anschließend ObjectType, Berechtigungsträger und AceType. Es weist auch auf lokalisierte Namen der Berechtigungsträger hin. Vergleichen Sie die bekannten SIDs, statt englische Kontonamen fest zu hinterlegen.

Die folgende schreibgeschützte PowerShell-Anpassung verwendet ADSI über .NET auf einer Windows-Administrationsarbeitsstation. Ersetzen Sie den Beispieldomänencontroller und den DN durch überprüfte Werte. Sie liest den Verzeichnissicherheitsdeskriptor direkt, außerhalb des ACL-Parsers des Collectors. Diese Befehle wurden für diesen Artikel nicht gegen eine Domäne ausgeführt.

Add-Type -AssemblyName System.DirectoryServices
$dc = 'dc01.example.test'
$dn = 'CN=Example User,OU=Users,DC=example,DC=test'
$entry = New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList "LDAP://$dc/$dn"
$entry.psbase.Options.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl
$descriptor = $entry.psbase.ObjectSecurity
$rules = @($descriptor.GetAccessRules(
    $true, $true, [System.Security.Principal.SecurityIdentifier]
))
$changePassword = [guid]'ab721a53-1e2f-11d0-9819-00aa0040529b'
$matchingDenies = @($rules | Where-Object {
    $_.ObjectType -eq $changePassword -and
    $_.AccessControlType -eq [System.Security.AccessControl.AccessControlType]::Deny -and
    $_.IdentityReference.Value -in @('S-1-1-0', 'S-1-5-10')
})
$matchingDenies | Select-Object IdentityReference, ObjectType,
    AccessControlType, ActiveDirectoryRights, IsInherited,
    InheritanceType, InheritanceFlags, PropagationFlags | Format-List
$entry.psbase.Dispose()

Die API-Referenzen dokumentieren ObjectSecurity, SecurityMasks und GetAccessRules. Sowohl explizite als auch geerbte Regeln werden angefordert; die Identitäten der Berechtigungsträger werden als SIDs zurückgegeben. Halten Sie die ungefilterten Regeln für eine umfassendere DACL-Prüfung verfügbar; der Filter wählt bewusst nur die in diesem Artikel behandelte Bedingung aus.

Falls die Bindung oder der Abruf des Sicherheitsdeskriptors fehlschlägt, bewahren Sie den Fehler auf und markieren Sie das Konto als ungeprüft. Eine unlesbare DACL ist keine leere DACL. Ersetzen Sie einen Prüfungsfehler nicht durch ein scheinbar erfolgreiches, unauffälliges Ergebnis.

Schritt 3: Die Struktur ohne übertriebene Schlussfolgerungen interpretieren

Beobachtetes Ergebnis	Zu erfassender Sachverhalt	Nächste Maßnahme
Everyone und SELF besitzen beide passende objektspezifische Deny-Einträge	Mögliche verweigerte Konfiguration mit zwei Berechtigungsträgern	Das Control-Access-Recht und die Anwendbarkeit der Regeln bestätigen, dann vor einer gezielten Änderung die Absicht prüfen
Nur ein Berechtigungsträger besitzt eine passende Deny-ACE	Zustand mit einem Berechtigungsträger, den das Detektorprädikat akzeptiert	Vollständige DACL prüfen; den Befund nicht verwerfen, weil der andere Eintrag fehlt
Nach erfolgreichem Lesen wird keine passende Deny-ACE zurückgegeben	Diese eng gefasste Bedingung wurde nicht gefunden	Fehlersuche fortsetzen; dies ist kein vollständiges Urteil über effektiven Zugriff oder Kennwortrichtlinie
DACL konnte nicht abgerufen werden	Nachweise fehlen	Lesefehler beheben, bevor eine Schlussfolgerung gezogen wird

Die Ausgabe enthält Informationen zu Rechten und Vererbung, damit die prüfende Person die Anwendbarkeit untersuchen kann. Der Filter prüft weder die Zugriffsmaske noch die Anwendbarkeit der Vererbung. Vergleichen Sie ein Paar vor der Einstufung als Microsoft-Standardkonfiguration mit der Maske ADS_RIGHT_DS_CONTROL_ACCESS und den ACE-Flags des Änderungsverfahrens. Dies ist ein gezieltes ACE-Inventar, keine vollständige Implementierung der Windows-Zugriffsprüfung. Umfassende Berechtigungen, andere Berechtigungsträger und nicht standardmäßige ACL-Anordnungen erfordern weitere Bewertung. Zählen Sie zwei passende ACEs auf einem Konto nicht als zwei betroffene Konten und verschiedene Lesevorgänge desselben DN nicht als verschiedene Identitäten.

Abhilfe: Eigene Kennwortänderung nur für freigegebene Konten wiederherstellen (Remediation)

Schritt 1: Absicht und Ausgangszustand dokumentieren

Weisen Sie jedem geprüften Konto einen Verantwortlichen zu und sichern Sie die DACL-Nachweise vor einer Änderung. Halten Sie fest, ob die eigene Kennwortänderung verfügbar sein soll, wer die Entscheidung genehmigt hat und welche betriebliche Abhängigkeit geprüft werden muss. Bleibt eine Beschränkung bestehen, dokumentieren Sie geschäftlichen Grund, zuständiges Team, Kennwortverwaltungsverfahren und Überprüfungszeitpunkt. Gewähren oder entfernen Sie Berechtigungen nicht über eine ganze OU hinweg, nur weil ein einzelner Benutzer einen Fehler gemeldet hat.

Prüfen Sie explizite und geerbte Regeln, bevor Sie die Änderung auswählen. Stammt die Beschränkung aus einer geerbten Regel, ermitteln Sie deren Ursprung und die betroffenen Konten. Eskalieren Sie die Entscheidung über diesen Umfang an den zuständigen Verzeichnisverantwortlichen, statt eine Änderung auf übergeordneter Ebene als Korrektur eines Einzelkontos zu behandeln.

Schritt 2: Eine gezielte Änderung vornehmen

Microsoft dokumentiert CannotChangePassword in Set-ADAccountControl. Das Beispiel beschreibt das Setzen des Sicherheitsdeskriptors des Benutzers. Die folgende Anpassung hebt die Beschränkung für ein freigegebenes Konto auf; zeigen Sie zunächst mit -WhatIf eine Vorschau an.

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -WhatIf

Sobald Ziel und Änderung genehmigt sind, führen Sie den Vorgang für das Einzelkonto mit Bestätigung aus:

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -Confirm

Dies sind dokumentierte Befehlsanpassungen, keine während dieser Prüfung ausgeführten Befehle. Eine Vorschau beweist nicht, dass der spätere Schreibvorgang erfolgreich war. Erfassen Sie das Ergebnis des tatsächlichen Vorgangs und prüfen Sie auf Fehler, bevor Sie zur Validierung übergehen.

Folgen Sie für eine eigene LDAP-Implementierung Microsofts Änderungsverfahren: Suchen Sie die Change Password-Einträge für beide Berechtigungsträger, ändern Sie deren objektspezifischen AceType auf Allow, ergänzen Sie fehlende Einträge mit der dokumentierten Control-Access-Maske und dem Objekttyp-Flag, und schreiben und bestätigen Sie dann den Sicherheitsdeskriptor. Beachten Sie beim Erstellen von Einträgen den Schritt zur ACL-Reihenfolge. Ersetzen Sie nicht die gesamte DACL durch ein minimales Regelpaar und entfernen Sie keine sachfremden Berechtigungen, um das Konto konform erscheinen zu lassen.

Schritt 3: Erneut lesen und den vorgesehenen Vorgang prüfen

Rufen Sie nach dem Schreibvorgang den Sicherheitsdeskriptor neu ab und wiederholen Sie Microsofts Leseverfahren. Vergleichen Sie beide Berechtigungsträger, die GUID und den AceType mit dem Ausgangszustand. Lassen Sie verbleibende geerbte Beschränkungen sichtbar. Eine erfolgreiche Befehlsantwort ist ein Zwischenartefakt; die DACL nach der Änderung ist der Berechtigungsnachweis.

Veranlassen Sie anschließend eine kontrollierte Prüfung der eigenen Kennwortänderung durch den Kontoverantwortlichen über den normalen Kennwortänderungsablauf. Halten Sie dieses Ergebnis vom DACL-Ergebnis getrennt. Scheitert der Vorgang weiterhin, untersuchen Sie den tatsächlichen Fehler und andere geltende Kontrollen, statt wiederholt die ACL zu ändern oder die Domänenrichtlinie abzuschwächen. Eine Helpdesk-Zurücksetzung ist nicht der Prüfschritt für die wiederhergestellte eigene Kennwortänderung.

Wie EtcSec diesen Zustand erkennt

Der Katalogbezeichner für diese Bedingung lautet USER_CANNOT_CHANGE_PASSWORD. In der geprüften Implementierung cannot-change.go untersucht Detect() die übergebenen ACL-Einträge und wählt diejenigen aus, bei denen:

ObjectType der Change Password-GUID entspricht, ohne Berücksichtigung der Groß- und Kleinschreibung;
AceType nach Umwandlung in Großbuchstaben DENIED enthält;
der Berechtigungsträger Everyone S-1-1-0 oder SELF S-1-5-10 ist.

Die ausgewählten Objekt-DNs werden in Kleinbuchstaben in einer Map gespeichert und anschließend mit Benutzer-DNs abgeglichen. So werden die passenden ACEs vor dem Aufbau der Liste betroffener Benutzer nach Konto-DN dedupliziert. Der Count des Befunds stammt aus dieser Liste; ein Disabled-Filter fehlt. Eine Allow-ACE erfüllt das Prädikat nicht, und die Implementierung liest zur Feststellung dieser Bedingung kein userAccountControl-Flag. Sie prüft auch weder die Zugriffsmaske noch die Anwendbarkeit der Vererbung; eine Prädikatübereinstimmung allein ist daher kein vollständiges Urteil über effektiven Zugriff.

Die Grenze der Datenerfassung ist die aktuelle Einschränkung. In public/internal/providers/ldap/acl_parser.go akzeptiert parseACE() nur die ACE-Typen ACCESS_ALLOWED und ACCESS_ALLOWED_OBJECT. Andere Typen geben nil zurück, einschließlich der hier erforderlichen Deny-ACEs. Ein korrektes Prädikat für übergebene Einträge belegt keine funktionierende Erkennung über den LDAP-Erfassungspfad. Dieser Artikel behauptet weder einen durchgängigen Collector-Test noch eine Validierung an einer realen Domäne.

Was im Prüfprotokoll aufzubewahren ist

Bewahren Sie für jedes Konto den exakten DN, abgefragten Controller, Zeitstempel, passende SIDs der Berechtigungsträger, ObjectType, Deny- oder Allow-Richtung sowie Rechte- und Vererbungskontext auf. Behalten Sie Prüfungsfehler, statt fehlgeschlagene Lesevorgänge wegzulassen. Ordnen Sie Vorher- und Nachher-Protokolle derselben Identität zu, einschließlich Änderungsgenehmigung oder Ausnahmeverantwortlichem.

Die Abschlussentscheidung sollte benennen, was festgestellt wurde: Eine Beschränkung blieb aus dokumentiertem Grund bestehen, eine Berechtigung wurde geändert und unabhängig erneut gelesen, oder weitere Untersuchungen bleiben offen. Erfassen Sie ein funktionales Ergebnis der eigenen Kennwortänderung nur, wenn die Prüfung tatsächlich durchgeführt wurde. Machen Sie aus dieser Quellenprüfung, einem Befehlsbeispiel, einer Zurücksetzung oder einem leeren Collector-Zähler keinen Nachweis erfolgreicher selbstständiger Kennwortrotation.