"Kennwort läuft nie ab" führt zu "Active Directory-Domänendienste-Fehler: Zugriff verweigert"

[lindner 0]

Hallo liebe Admins,

 

ich habe hier eine merkwürdige Situation, die ich mir nicht erklären kann. Wenn ich im AD mit dem Administrator-Account unserer Domäne das Feld "Kennwort läuft nie ab" bei irgendeinem Nutzer setzen möchte und anschließend speichere, erhalte ich die Fehlermeldung "Active Directory-Domänendienste-Fehler: Zugriff verweigert". Das Häkchen selbst bleibt natürlich auch nicht gespeichert. Mir schein also, dem Administratorkonto fehlt hier ein Recht. Wechsele ich dann in dem zu veränderndem Nutzerkonto auf die Registerkarte "Sicherheit" und lasse mir den effektiven Zugriff für den Administrator anzeigen, sehe ich dort nur grüne Häkchen.

 

Nun fällt mir die Analyse äußerst schwer, da ich eigentlich Anwendungsentwickler bin und hier in unserem kleinen Betrieb die Administration nur aus Affinitätsgründen mitmache. Bin also bei Weitem kein Administrations-Profi. Ich weiß also in diesem Moment nicht, was der nächste logische Schritt wäre. Kann jemand einen Denkanstoß bieten?

 

Zuvor (auch schon zwei Jahre her) habe ich weitestgehend den BSI-Grundschutz (manuelles durcharbeiten der Templates) und LAPS eingerichtet. Ich könnte mir vorstellen, dass vielleicht eines dieser Änderungen damit zu Tun haben könnte?

 

Edit: betreffendes Betriebssystem: Windows Server 2019 Standard

 

Inbrünstig auf eine Idee hoffend,

 

Jan

bearbeitet Montag um 12:33 von lindner

[NorbertFe 2.110]

Was ist denn das für ein Benutzerkonto, auf dem du den Haken setzen möchtest. Kann es sein, dass da Verweigerungen greifen oder die Vererbung der Sicherheit deaktiviert wurde?

[lindner 0]

vor einer Stunde schrieb NorbertFe:

Was ist denn das für ein Benutzerkonto, auf dem du den Haken setzen möchtest. Kann es sein, dass da Verweigerungen greifen oder die Vererbung der Sicherheit deaktiviert wurde?

 

Es ist ein ganz normales Benutzerkonto (also kein Admin). Es geht aber nicht nur um dieses Konto - ich kann es über den Administrator bei keinem Benutzer durchführen. Alle anderen Einstellungen kann ich tätigen, nur nicht "Kennwort läuft nie ab" oder "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" (aber Letzteres wäre mir egal).

 

Ich würde bei greifenden Verweigerungen auf der Seite "Effektiver Zugriff" dann rote Kreuzchen sehen, oder? Dort sind nur grüne Häkchen, also Alles erlaubt.

 

Ich habe versucht, herauszufinden, ob die Vererbung der Sicherheit deaktiviert wurde - da ich den Knopf "Vererbung deaktivieren" in den erweiterten Sicherheitseinstellungen sehen kann, gehe ich mal davon aus, dass die Vererbung noch aktiv ist. Oder muss ich das anders prüfen?

[Sunny61 812]

Machst Du das auf dem DC oder auf einem Client?

[cj_berlin 1.359]

Moin,

 

die beiden Häkchen sind aber zwei verschiedene Attribute. "Muss Kenwort ändern" ist pwdLastSet (setzen --> 0, entfernen --> aktueller Zeitstempel), "Kennwort läuft nicht ab" ist ein Bit in userAccoutControl. Wenn im "Effektiven Zugriff" tatsächlich grüne Häkchen fürs Schreiben dieser beiden Attribute zu finden ist, schau Dir die effektiven Berechtigungen desselben Users am Root-Knoten der Domäne. Dort gibt es spezielle Berechtigungen wie "Unexpire Password", die auch verweigert werden könnten. Vielleicht wirst Du da fündig.

[lindner 0]

vor 3 Minuten schrieb Sunny61:

Machst Du das auf dem DC oder auf einem Client?

 

Auf dem DC.

[cj_berlin 1.359]

vor 3 Minuten schrieb Sunny61:

Machst Du das auf dem DC oder auf einem Client?

 Du meinst, wegen UAC und so?  Ja, gute Frage. @lindner wenn Du direkt auf dem DC hockst, musst Du die Werkzeuge, mit denen Du das AD bearbeitest, "Als Administrator" starten.

 

Vermutlich hast Du bei Deinem BSI-Durchlauf die Benutzerkontensteuerung für DCs auf "Automatisch verweigern" gestellt. Noch ein Grund, sich nicht interaktiv auf DCs anzumelden  

 

[lindner 0]

vor 8 Minuten schrieb cj_berlin:

 Du meinst, wegen UAC und so?  Ja, gute Frage. @lindner wenn Du direkt auf dem DC hockst, musst Du die Werkzeuge, mit denen Du das AD bearbeitest, "Als Administrator" starten.

 

Vermutlich hast Du bei Deinem BSI-Durchlauf die Benutzerkontensteuerung für DCs auf "Automatisch verweigern" gestellt. Noch ein Grund, sich nicht interaktiv auf DCs anzumelden  

 

 

Ich habe es gerade mal ausprobiert: "Als Administrator" starten ändert nichts am Verhalten. Macht das wirklich einen Unterschied? Ich bin doch bereits Administrator...

 

Ist eine von den Einstellungen, die im angehängten Bild gezeigt sind, eine von denen, die Du meinst?

[cj_berlin 1.359]

vor 1 Minute schrieb lindner:

Ich habe es gerade mal ausprobiert: "Als Administrator" starten ändert nichts am Verhalten. Macht das wirklich einen Unterschied? Ich bin doch bereits Administrator...

Nein, bist Du nicht. Das müsstest Du auch als Anwendungsentwickler wissen, wenn Du für Windows entwickelst. UAC kann man entfernt mit sudo vergleichen - Du hast das Recht, dir Adminrechte zu nehmen, aber Du hast sie (d.h. Privilegien in Deinem Token) nicht von vornherein in Deiner interaktiven Sitzung.

Deine Einstellungen (ja, es sind die Richtigen) sind soweit in Ordnung. Wenn der Screenshot aus dem GPResult kommt natürlich  

 

Versuch's zu Sicherheit von einem Member mit installiertem AD-RSAT aus. Falls das auch nicht hinhaut, schau nach den Berechtigungen auf Domänen-Ebene, die ich vorhin erwähnt habe.

[Sunny61 812]

vor 2 Stunden schrieb cj_berlin:

Du meinst, wegen UAC und so?  Ja, gute Frage.

Genau, wäre ja nicht das erste mal. ;)

[lindner 0]

vor 17 Stunden schrieb cj_berlin:

Nein, bist Du nicht. Das müsstest Du auch als Anwendungsentwickler wissen, wenn Du für Windows entwickelst. UAC kann man entfernt mit sudo vergleichen - Du hast das Recht, dir Adminrechte zu nehmen, aber Du hast sie (d.h. Privilegien in Deinem Token) nicht von vornherein in Deiner interaktiven Sitzung.

Deine Einstellungen (ja, es sind die Richtigen) sind soweit in Ordnung. Wenn der Screenshot aus dem GPResult kommt natürlich  

 

Versuch's zu Sicherheit von einem Member mit installiertem AD-RSAT aus. Falls das auch nicht hinhaut, schau nach den Berechtigungen auf Domänen-Ebene, die ich vorhin erwähnt habe.

 

Stimmt, da war was mit den Token. Ist lange her, dass ich mich damit herumärgern musste

 

GPResult habe ich durchlaufen lassen und das Ergebnis ist deckungsgleich mit meinem Screenshot.

 

Die RSAT kannte ich noch gar nicht - wie praktisch! Leider habe ich auch darüber den gleichen Fehler.

 

Ich werde mich jetzt durch die Berechtigungen auf Domänen-Ebene durchwühlen, das sind ja eine ganze Menge mit sehr kryptischen Namen :(

[lindner 0]

So, ich hoffe, ich kann das hier irgendwie sinnvoll ausdrücken...

 

Aufgrund @cj_berlin's Hinweis, dass es hier um das setzen von Bits im Attribut userAccountControl geht, habe ich versuchsweise mal die direkte Manipulation probiert. Hier habe ich keinen Zugriff, was ja zu erwarten war (Screenshot anhängend).

 

In den Sicherheitseinstellungen des Nutzers, den ich verändern will, kann ich sehen, dass die Berechtigung "userAccountControl schreiben" gesetzt ist (Screenshot anhängend).

 

In meinem Denken würde dies bedeuten, dass ich Zugriff auf das Feld habe, denn dieser Bereich heißt ja "effektive Berechtigungen" - ich gehe also davon aus, dass ein Ausschluß auf Domänenebene hier auch zu einem roten Kreuz führen würde. Dennoch bin ich an den root-Knoten gegangen um zu prüfen, ob dort irgendeine Art von Verbot existiert. Dort finde ich dann beim Effektiven Zugriff allerdings gar keine Erwähnung des Feldes userAccountControl. Ich habe ein paar andere Felder gefunden, die zwar etwas mit Kennwörtern zu tun haben, aber meines Erachtens unpassend sind (2 weitere Screenshots anhängend). Zumindest kann ich sehen, dass gewisse Verbote existieren, wie z.B. "Alle erweiterten Rechte", was auch immer das ist.

 

Aber: Wenn nun kein explizites Verbot für "userAccountControl" existiert, SOLLTE ich doch eigentlich Zugriff haben, oder? Oder sind auf Root-Ebene manche Berechtigungen in Grüppchen zusammengefasst, deren Namen ich bloß nicht kenne? Findet sich das gesuchte Recht vielleicht in etwas anderem wie "erweiterte Rechte" (nur als Beispiel)? Muss ich entlang des Baumes auch alle untergeordneten Objekte der Baumstruktur in Richtung meines zu verändernden Benutzers auf Verbote kontrollieren?