mc-doubleyou
Goto Top

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.

Set-ADUser user -ChangePasswordAtLogon $true
auch kombiniert mit einer Deaktivierung und Aktivierung des Accounts

$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!

Content-Key: 467988

Url: https://administrator.de/contentid/467988

Printed on: April 24, 2024 at 07:04 o'clock

Member: Looser27
Looser27 Jul 01, 2019 at 14:55:05 (UTC)
Goto Top
Member: mc-doubleyou
mc-doubleyou Jul 01, 2019 at 15:15:23 (UTC)
Goto Top
Hallo Looser27,

super Script und geht auch in die gleich Richtung wie wir es geplant haben, wobei ich die Identifikation der User simpler gestalten wollte.

so in diese Richtung (PseudoCode)

if (PasswordLastSet.toString(dd.MM.yyyy) -eq get-date.AddDays(1)) { dann ... }

Es bleibt aber das Problem, dass bei Nutzung von:

Set-ADUser -identity:($_.samaccountname) -ChangePasswordAtLogon:$True

Ein Login klappt und erst beim zweiten mal der Passwortwechsel Dialog kommt

Trotzdem Danke!
Member: Looser27
Looser27 Jul 01, 2019 updated at 15:25:48 (UTC)
Goto Top
Ich habe den Wert in der Zeile

if($diff -lt 1)

auf 2 gesetzt. Damit wird der Wechsel in der Nacht erzwungen. Das Skript wird bei mir über die Aufgabenplanung ausgeführt.
Member: mc-doubleyou
mc-doubleyou Jul 03, 2019 updated at 08:59:24 (UTC)
Goto Top
Hallo Looser27,

gefühlt macht das keinen Unterschied aber evtl. übersehe ich auch etwas darum werde ich unten dein Script kommentieren.

# Import des AD Moduls
Import-Module ActiveDirectory
# setzen der Variable maxSpan auf das maximale Passwortalter laut Policy
$maxSpan = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge
# setzen der Variable today auf das heute Datum und Zeit
$today = get-date 
 
# AD User auswählen die aktiv sind und bei denen das Passwort nicht niemals ausläuft, inkl der Property PasswordLastSet (ist normal nicht dabei)
get-aduser -Filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} -Properties PasswordLastSet,GivenName,Surname,samaccountname -SearchBase “DC=mydomain,DC=intern” -SearchScope Subtree |

# Auswahl alle User bei denen PasswordLastSet den heutigen Datum entspricht
?{$_.PasswordLastset -is [datetime]} | 

# Für jeden User die Variable diff setzen: DateTime des gesetzen Passwords + maximales Passwortalter + DateTime von heute (Ergebnis in Tagen)
%{$diff = (($_.PasswordLastSet + $maxSpan)-$today).Days
   
    # Wenn Variable diff kleiner 1 
    if($diff -lt 1)
	{ 
        # User Passwort auf wechseln beim nächsten Login setzen
    	Set-ADUser -identity:($_.samaccountname) -ChangePasswordAtLogon:$True
    	} 
}

Ändere ich 1 auf 2 muss der User nur einen Tag früher wechseln, was aber nichts daran ändert, dass nicht unmittelbar nach der Einstellung das Passwort zu wechseln ist, sondern ein Login möglich ist. Jedenfalls bei uns.

LG mcdy
Member: Looser27
Solution Looser27 Jul 03, 2019 updated at 09:11:42 (UTC)
Goto Top
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.
Member: mc-doubleyou
mc-doubleyou Jul 03, 2019 at 14:04:01 (UTC)
Goto Top
Es scheint als würden wir uns dem Problem nähern - danke schon mal ;)

Wir haben auch VPN Clients und die müssen natürlich im schlimmsten Fall den Login erlauben auch wenn das Passwort nicht mehr gültig sein sollte.
Aber für WLAN werde ich mir die GPO mal suchen, bzw. einen Test machen am Kabel - ist ja eigentlich nur WLAN geworden wegen des ED(Faul)ers ^^

Meld mich wieder!
LG mcdy
Member: mc-doubleyou
mc-doubleyou Jul 03, 2019 at 14:27:24 (UTC)
Goto Top
Die Aussage klang so logisch, aber leider nein.
Auch mit LAN ein Login nachdem in der AD auf "ChangePasswordAtLogon" umgestellt wurde möglich.
Mit genau dem selben Bild (keine Share Zugriffe, etc.) und der Meldung von MS selbst, dass man sich erneut einloggen soll.

Ich werde es nun noch mit einem Stand PC testen, vermute aber da dürfte es keinen Unterschied geben.
Sonst noch eine Idee?

Danke!
LG mcdy
Member: mc-doubleyou
mc-doubleyou Jul 03, 2019 at 15:23:21 (UTC)
Goto Top
Hallo Winer27 ;)

ich habe mir deinen Vorschlag nochmal genauer angesehen und verstehe nun was du mir damit sagen wolltest.
https://www.windows-faq.de/2017/10/19/beim-neustarten-des-computers-und- ...

Diese GPO verhindert nciht den Offline Login sondern sorgt dafür, dass die GPOs vor dem Login angewendet werden wenn möglich.
Warum das nicht Standard ist verstehe wer will.

Jedenfalls klappt es nun, rund 10s nachdem ich auf "ChangePasswordAtLogon" setze kommt bei der Anmeldung schon der Wechseldialog.

Bist mein Held des Tages!
LG mcdy
Member: mc-doubleyou
mc-doubleyou Jul 04, 2019 at 13:26:38 (UTC)
Goto Top
Hallo,

falls es dich interessiert so sieht mein Script aus:

# aktivierte AD Benutzer bei denen dass Passwort ablaufen kann und der Passwortwechselzwang noch nicht aktiviert wurde
$ADUser = Get-ADUser -Filter {Enabled -eq $true -and PasswordNeverExpires -eq $false} -Properties SamAccountName,PasswordLastSet -SearchBase "OU=User,DC=company,DC=my" | Where-Object {$_.PasswordLastSet -ne $null}  


$ADUser | ForEach-Object {
    # wenn Datum des letzten Passwortwechsel + maximal Alter des Passwort im Format yyyy-MM-dd gleich wie Datum von morgen im gleichen Format
    if ($_.PasswordLastSet.AddDays((Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge.Days).ToString("yyyy-MM-dd") -eq (Get-Date).AddDays(1).ToString("yyyy-MM-dd"))  
        {
            # erzwungenen Passwortwechsel aktivieren
            Set-ADUser $_.SamAccountName -ChangePasswordAtLogon $true
        }
    }

Den Teil mit dem Auslesen aus der Policy habe ich mir abgesehen, finde ich praktisch falls es sich mal ändert.

LG mcdy