lindner 0 Geschrieben 27. Januar Melden Geschrieben 27. Januar (bearbeitet) 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 27. Januar von lindner Zitieren
NorbertFe 2.155 Geschrieben 27. Januar Melden Geschrieben 27. Januar 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? Zitieren
lindner 0 Geschrieben 27. Januar Autor Melden Geschrieben 27. Januar 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? Zitieren
Sunny61 816 Geschrieben 27. Januar Melden Geschrieben 27. Januar Machst Du das auf dem DC oder auf einem Client? Zitieren
cj_berlin 1.394 Geschrieben 27. Januar Melden Geschrieben 27. Januar 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. Zitieren
lindner 0 Geschrieben 27. Januar Autor Melden Geschrieben 27. Januar vor 3 Minuten schrieb Sunny61: Machst Du das auf dem DC oder auf einem Client? Auf dem DC. Zitieren
cj_berlin 1.394 Geschrieben 27. Januar Melden Geschrieben 27. Januar 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 Zitieren
lindner 0 Geschrieben 27. Januar Autor Melden Geschrieben 27. Januar 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? Zitieren
cj_berlin 1.394 Geschrieben 27. Januar Melden Geschrieben 27. Januar 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. Zitieren
Sunny61 816 Geschrieben 27. Januar Melden Geschrieben 27. Januar vor 2 Stunden schrieb cj_berlin: Du meinst, wegen UAC und so? Ja, gute Frage. Genau, wäre ja nicht das erste mal. ;) Zitieren
lindner 0 Geschrieben 28. Januar Autor Melden Geschrieben 28. Januar 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 :( Zitieren
lindner 0 Geschrieben 28. Januar Autor Melden Geschrieben 28. Januar 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? Zitieren
daabm 1.384 Geschrieben 6. Februar Melden Geschrieben 6. Februar Verschaff Dir Vollzugriff dann geht es auf jeden Fall. Ich weiß leider nicht auswendig, was genau hinter den extendedRights steckt, macht alles meistens ein Kollege. Zitieren
lindner 0 Geschrieben 10. Februar Autor Melden Geschrieben 10. Februar Am 6.2.2025 um 18:17 schrieb daabm: Verschaff Dir Vollzugriff dann geht es auf jeden Fall. Ich weiß leider nicht auswendig, was genau hinter den extendedRights steckt, macht alles meistens ein Kollege. Davon hatte ich bisher immer abgesehen, aus Angst, dann irgendwie eine Sicherheitslücke aufzureißen. Ich habe es jetzt mal ausprobiert, aber keinen Erfolg. Irgendwo ist da der Wurm drin... Anbei zwei Screenshots vom obersten Domänenknoten: Im ersten sieht man, dass ich Vollzugriff für den Administrator eingestellt habe: Im zweiten ist jedoch ersichtlich, dass der Vollzugriff dann wieder eingeschränkt ist: Wie komme ich der Ursache auf den Grund? Zitieren
Nobbyaushb 1.506 Geschrieben 10. Februar Melden Geschrieben 10. Februar Was mich in dem Zusammenhang interessieren würde, ist der User mit dem du dich angemeldet hast der Domain Admin oder ein anderer User mit erhöhten Rechten? Dem Domain-Admin kann man eigentlich nichts verweigern… Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.