W2K22 - lokales Adminpasswort kann nicht geändert werden.

[NorbertFe 1.812]

Gerade eben schrieb daabm:

Hier geht's genau um Passwortrichtlinen, also genau um die Ausnahme...

Ja aber doch für lokale Konten und da würde die auf Domänenebene vermutlich trotzdem greifen. ;)

[daabm 1.187]

Für lokale Konten gilt das gleiche wie für Domänenkonten. Ist die Kennwortrichtlinie in einem GPO, das an der Domäne verlinkt ist, wird es von Membern nicht verarbeitet und gilt nicht für lokale Konten. Ist es "irgendwo" anders verlinkt, gilt es _ausschließlich_ für lokale Konten. Wenn der Computer noch in CN=Computers ist, greifen - korrekt, klar - keine GPOs, und eine Policy als Quelle von PW-Regeln scheidet schlicht aus. Kann dann nur noch eine lokale Einstellung sein -> go to "secpol.msc".

[wznutzer 32]

Guten Morgen,

 

ich will mal versuchen alle Fragen zu beantworten.

vor 15 Stunden schrieb NilsK:

nur vorsichtshalber: hast du die Kennwortrichtlinie lokal überprüft? In einem CMD mit

net accounts

 

hast du geprüft, dass du über das GUI auch tatsächlich das lokale Adminkonto änderst?

 

vor 14 Stunden schrieb Nobbyaushb:

Außerdem müsste man wissen, ob du als lokaler User (Administrator) oder mit einem Domänen-Account angemeldet bist.

 

Ja, ganz sicher als lokaler User angemeldet. Ich will ja auch das Passwort des lokalen Administrator ändern. "net accounts" hatte ich zum damaligen Zeitpunkt noch nicht geprüft, zwischenzeitlich aber "net user Administrator". Da hat es dann auch Klick gemacht.

 

Auflösung (wahrscheinlich)

Wenn ich W2K22 über Lenovo XClarity installiere, gibt mir "net user Administrator" Kennwort änderbar 1 Tag in der Zukunft aus. Das letzte Setzen des Kennworts ist der Installationszeitpunkt. Somit müsste das minimale Kennwortalter auf 1 stehen. Nach einen gpupdate /force ist Kennwort änderbar nicht mehr 1 Tag in der Zukunft und ich kann das Kennwort ändern. "net accounts" habe ich erst nach dem gpupdate /force durchgeführt, ich kann nicht sagen was vorher war. Nach gpupdate /force wird die Domänenrichtlinie angezeigt.

 

Nicht erklären kann ich mir, warum ich das Kennwort über die Computerverwaltung setzen konnte. Nach dem gpupdate /force verhält sich die Kennwortänderung über die Computerverwaltung gleich wie über STRG + ALT + ENTF.

 

vor 14 Stunden schrieb daabm:

Für lokale Konten gilt das gleiche wie für Domänenkonten. Ist die Kennwortrichtlinie in einem GPO, das an der Domäne verlinkt ist, wird es von Membern nicht verarbeitet und gilt nicht für lokale Konten. Ist es "irgendwo" anders verlinkt, gilt es _ausschließlich_ für lokale Konten. Wenn der Computer noch in CN=Computers ist, greifen - korrekt, klar - keine GPOs, und eine Policy als Quelle von PW-Regeln scheidet schlicht aus. Kann dann nur noch eine lokale Einstellung sein -> go to "secpol.msc".

 

Das kann ich nun nicht nachvollziehen. Das Computerkonto ist in "Computers", die Kennwortrichtlinie ist auf Domänenebene verlinkt. Ich kann aber für *lokale* Konten keine Kennwörter vergeben die gegen diese Richtlinie verstoßen. Evtl. übersehe ich was, aber es sieht so aus als ob die Richtlinie auch für Computerkonten in Computers verarbeitet und durchgesetzt wird. Ich habe das gerade noch mit einer frischen W10 VM versucht, auch da ist es so. Testweise habe ich mal die Passwortlänge hochgesetzt ==> gpupdate /force ==> es werden keine Kennwörter für lokale Konten mit kleinerer Länge akzeptiert. "net accounts" zeigt mir dann auch die neue größere Länge an.

 

Vielen Dank für eure Mühe

[NilsK 2.789]

Moin,

 

na, dann hat es sich ja geklärt. Das ist auch plausibel.

 

vor 33 Minuten schrieb wznutzer:

Nicht erklären kann ich mir, warum ich das Kennwort über die Computerverwaltung setzen konnte.

Weil du in dem Fall das Kennwort als Administrator zurücksetzt. Das ist immer möglich, unabhängig von den Zeitbeschränkungen. Dass es sich dabei zufällig um dein eigenes Konto handelt, ändert nichts daran.

Per Affengriff hingegen ändert der User selbst sein eigenes Kennwort. Das ist durch die Regeln eingeschränkt.

 

Gruß, Nils

 

[wznutzer 32]

vor 50 Minuten schrieb NilsK:

Weil du in dem Fall das Kennwort als Administrator zurücksetzt. Das ist immer möglich, unabhängig von den Zeitbeschränkungen.

Das wichtige Wort hier ist wohl *Zeitbeschränkungen*. Beim Zurücksetzen kann ich mich darüber hinwegsetzen, aber nicht über die Längen- und/oder Komplexitätsrichtlinien. So jedenfalls gerade getestet.

[NilsK 2.789]

Moin,

 

ja, genau.

 

Gruß, Nils

 

[daabm 1.187]

vor 9 Stunden schrieb wznutzer:

Das Computerkonto ist in "Computers", die Kennwortrichtlinie ist auf Domänenebene verlinkt. Ich kann aber für *lokale* Konten keine Kennwörter vergeben die gegen diese Richtlinie verstoßen.

 

Asche auf mein Haupt - ich bin Ü50, bitte hilf mir über die Straße

 

Das gilt nur für Domain Controller - der PDC ist der einzige DC, der PW-Policies verarbeitet. Für alle "normalen" Member in der Domäne gilt das ganz normale Vererbungsprinzip bis hoch zur Domäne. Keine Ahnung, welchen mentalen Aussetzer ich da hatte

[cj_berlin 1.150]

vor 6 Minuten schrieb daabm:

 

Asche auf mein Haupt - ich bin Ü50, bitte hilf mir über die Straße

 

Das gilt nur für Domain Controller - der PDC ist der einzige DC, der PW-Policies verarbeitet. Für alle "normalen" Member in der Domäne gilt das ganz normale Vererbungsprinzip bis hoch zur Domäne. Keine Ahnung, welchen mentalen Aussetzer ich da hatte 

Ich hatte mich schon gewundert - es gibt sicher Dinge, die ich über AD noch nicht weiß, aber dass mir solche Basics über all die Jahre entgangen wären, das hat mir schon Angst gemacht. Aber wenn Martin das sagt, dachte ich mir...

[daabm 1.187]

vor 8 Minuten schrieb cj_berlin:

Aber wenn Martin das sagt, dachte ich mir...

Würde mir umgekehrt genauso gehen - und deshalb "open failure committment" Ich mach bestimmt viel richtig (wie die meisten hier), aber wenn ich mal was falsch mache, dann darf das auch klar und eindeutig ersichtlich sein.

[NorbertFe 1.812]

vor 58 Minuten schrieb daabm:

welchen mentalen Aussetzer ich da hatte

Es war schon spät gestern. ;)