Windows 10 Login möglich trotz "ChangePasswordAtLogon"
Hallo zusammen,
ich hoffe ihr bringt Licht in die Sache, weil ich bin mit meinem Latein leider am Ende.
Wir haben Windows 10 Computer mit aktuell noch 1709 (ich sage es extra dazu nicht das es ein bekannter Bug in der Version wäre).
Außerdem AD Accounts, welche alle 30 Tage das Passwort wechseln müssen.
Wie euch vermutlich bekannt, für mich war es neu und finde diese Lösung auch absolut dämlich, läuft das Passwort nicht etwa um 00:00 ab sondern exakt zur selben Zeit an der es gesetzt wurde.
Somit kommt es aktuell vor, dass Users sich in der früh einloggen können und plötzlich um zB. 11:00 die Verbindung zu Share und Exchange nicht mehr möglich ist weil das Passwort abgelaufen ist.
Dem wollte ich ursprünglich entgegen treten in dem ich PasswordLastSet auf ursprüngliches Datum aber 00:00:00 setzen wollte, geht aber nicht dieses Attribut kann nur durch das System auf einen DateTime Wert gesetzt werden. Selbst kann nur 0 (gleichzusetzen mit "ChangePasswordAtLogon") und -1 (gleichzusetzen mit "PasswordNeverExpires") gesetzt werden.
Also haben wir uns einen anderen Ansatz überlegt, immer wenn das Passwort morgen ablaufen wird soll per Script "ChangePasswordAtLogon" gesetzt werden.
Das Problem ist, trotz der Einstellung kann ich mich einmalig einloggen, dann bekomme ich aber natürlich keinen Share und Exchange Zugriff und erst beim zweiten Login wird der Passwortwechsel Dialog durchgeführt.
Ich habe schon versucht "ChangePasswordAtLogon" wie folgt zu setzen, allerdings ändert das nichts an dem seltsamen Verhalten.
auch kombiniert mit einer Deaktivierung und Aktivierung des Accounts
Client ist per WLAN verbunden, wenn es über VPN nicht besser geht würde ich es ja verstehen.
Ich hoffe irgend jemand da draußen kann mir zumindest erklären was da abläuft oder noch besser kennt die Lösung.
Danke mcdy!
ich hoffe ihr bringt Licht in die Sache, weil ich bin mit meinem Latein leider am Ende.
Wir haben Windows 10 Computer mit aktuell noch 1709 (ich sage es extra dazu nicht das es ein bekannter Bug in der Version wäre).
Außerdem AD Accounts, welche alle 30 Tage das Passwort wechseln müssen.
Wie euch vermutlich bekannt, für mich war es neu und finde diese Lösung auch absolut dämlich, läuft das Passwort nicht etwa um 00:00 ab sondern exakt zur selben Zeit an der es gesetzt wurde.
Somit kommt es aktuell vor, dass Users sich in der früh einloggen können und plötzlich um zB. 11:00 die Verbindung zu Share und Exchange nicht mehr möglich ist weil das Passwort abgelaufen ist.
Dem wollte ich ursprünglich entgegen treten in dem ich PasswordLastSet auf ursprüngliches Datum aber 00:00:00 setzen wollte, geht aber nicht dieses Attribut kann nur durch das System auf einen DateTime Wert gesetzt werden. Selbst kann nur 0 (gleichzusetzen mit "ChangePasswordAtLogon") und -1 (gleichzusetzen mit "PasswordNeverExpires") gesetzt werden.
Also haben wir uns einen anderen Ansatz überlegt, immer wenn das Passwort morgen ablaufen wird soll per Script "ChangePasswordAtLogon" gesetzt werden.
Das Problem ist, trotz der Einstellung kann ich mich einmalig einloggen, dann bekomme ich aber natürlich keinen Share und Exchange Zugriff und erst beim zweiten Login wird der Passwortwechsel Dialog durchgeführt.
Ich habe schon versucht "ChangePasswordAtLogon" wie folgt zu setzen, allerdings ändert das nichts an dem seltsamen Verhalten.
Set-ADUser user -ChangePasswordAtLogon $true
$ADPath = "AD:\" + (get-aduser user -Properties * | select distinguishedName).distinguishedName
Set-ItemProperty -Path $ADPath -Name pwdLastSet -Value "0" -Force
Client ist per WLAN verbunden, wenn es über VPN nicht besser geht würde ich es ja verstehen.
Ich hoffe irgend jemand da draußen kann mir zumindest erklären was da abläuft oder noch besser kennt die Lösung.
Danke mcdy!
Please also mark the comments that contributed to the solution of the article
Content-Key: 467988
Url: https://administrator.de/contentid/467988
Printed on: April 24, 2024 at 07:04 o'clock
9 Comments
Latest comment
Nimm doch zum Testen mal das Skript aus dem Link oben. Mit der Option -whatif kannst Du das gefahrlos testen.
Ich denke, der Fehler liegt irgendwo in der Abfrage des Usernames. Offensichtlich wird der erst beim 2. Mal bei Dir korrekt erkannt.
*Stirn patsch*
Hast Du bei die Option "Auf Netzwerkverbindung warten" in den GPOs für die WLAN-Clients gesetzt?
Ansonsten ist das von Dir genannte Verhalten nämlich normal. Der Client kann ohne Verbindung zum DC nur das lokal gespeicherte Passwort verwenden bei der Anmeldung. Ist auch logisch..... Hat er aber einmal Kontakt zur Domain, wird das Häkchen gesetzt.
Ich denke, der Fehler liegt irgendwo in der Abfrage des Usernames. Offensichtlich wird der erst beim 2. Mal bei Dir korrekt erkannt.
*Stirn patsch*
Hast Du bei die Option "Auf Netzwerkverbindung warten" in den GPOs für die WLAN-Clients gesetzt?
Ansonsten ist das von Dir genannte Verhalten nämlich normal. Der Client kann ohne Verbindung zum DC nur das lokal gespeicherte Passwort verwenden bei der Anmeldung. Ist auch logisch..... Hat er aber einmal Kontakt zur Domain, wird das Häkchen gesetzt.