5
LastlogonDate ist falsch
Hallo zusammen,
ich habe auf einem W2012R2 AD eine Passwortrichtlinie erstellt, welche die User zwingt, das PW nach 90 Tagen zu ändern.
Als Kontrolle habe ich einfach ein Powershell Script gemacht, welches alle User mit diesen Werten auflistet: select Name, SamAccountName, Enabled, PasswordNeverExpires, PasswordExpired, PasswordLastSet, LockedOut, LastLogonDate, AccountExpirationDate
Manche User haben die Umstellung nicht gemacht, da sie Abwesend sind. Dort wurde der Haken "Kennwort bei der nächsten Anmeldung ändern" gesetzt. Alle diese User haben nun das PW Alter: 43655.
Das Problem ist, dass bei LastLogonDate Werte stehen, die gestern, bzw. diesen Monat waren. Durch den Haken müssten die User ja ihr Passwort ändern - somit würde das PW Alter einen reset bekommen.
Im Internet steht, dass der Wert nicht so zuverlässig sein soll ?
Kann mir hier evtl. jemand Hilfe anbieten? :D
Gruß Berggg
ich habe auf einem W2012R2 AD eine Passwortrichtlinie erstellt, welche die User zwingt, das PW nach 90 Tagen zu ändern.
Als Kontrolle habe ich einfach ein Powershell Script gemacht, welches alle User mit diesen Werten auflistet: select Name, SamAccountName, Enabled, PasswordNeverExpires, PasswordExpired, PasswordLastSet, LockedOut, LastLogonDate, AccountExpirationDate
Manche User haben die Umstellung nicht gemacht, da sie Abwesend sind. Dort wurde der Haken "Kennwort bei der nächsten Anmeldung ändern" gesetzt. Alle diese User haben nun das PW Alter: 43655.
Das Problem ist, dass bei LastLogonDate Werte stehen, die gestern, bzw. diesen Monat waren. Durch den Haken müssten die User ja ihr Passwort ändern - somit würde das PW Alter einen reset bekommen.
Im Internet steht, dass der Wert nicht so zuverlässig sein soll ?
Kann mir hier evtl. jemand Hilfe anbieten? :D
Gruß Berggg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 475238
Url: https://administrator.de/contentid/475238
Ausgedruckt am: 19.11.2024 um 11:11 Uhr
5 Kommentare
Neuester Kommentar
Hi,
Verstehe ich Dich richtig?
Du wunderst Dich, dass da bei einigen Benutzern ein LastLogonDate drin steht, welches jünger ist als PasswordLastSet, obwohl Du noch vor diesem LastLogonDate eingestellt hast, dass dieser Benutzer bei der nächsten Anmeldung sein Passwort ändern müsse.
Fall ja:
"bei der nächsten Anmeldung" bedeutet "beim Herstellen einer neuen Sitzung". Wenn da irgdendwo eine ununterbrochen laufende Sitzung eines dieser Konten besteht, dann wird diese sich regelmäßig erneut beim DC authentifizieren. Und da das alte Passwort defacto noch korrekt ist, wird die laufende Sitzung also erneut authentifiziert. Daher der neue Zeitstempel im LastLogonDate.
"beim Herstellen einer neuen Sitzung" tritt ein
Es ist also anzunehmen, dass diese Benutzer entweder Ihre PC's noch laufen haben und dort angemeldet sind, oder dass diese irgendwo getrennte RDP-Sitzungen am Laufen haben.
E.
Im Internet steht, dass der Wert nicht so zuverlässig sein soll ?
LastLogonDate sagt aus, wann dieses Konto zuletzt von diesem DC (den man abfragt) authentifiziert wurde. Dieses Attribut wird nicht repliziert. Wenn man da eine zuverlässige Aussage haben will, dann muss man alle DC einer Domäne abfragen und das jüngste Datum gilt dann.Verstehe ich Dich richtig?
Du wunderst Dich, dass da bei einigen Benutzern ein LastLogonDate drin steht, welches jünger ist als PasswordLastSet, obwohl Du noch vor diesem LastLogonDate eingestellt hast, dass dieser Benutzer bei der nächsten Anmeldung sein Passwort ändern müsse.
Fall ja:
"bei der nächsten Anmeldung" bedeutet "beim Herstellen einer neuen Sitzung". Wenn da irgdendwo eine ununterbrochen laufende Sitzung eines dieser Konten besteht, dann wird diese sich regelmäßig erneut beim DC authentifizieren. Und da das alte Passwort defacto noch korrekt ist, wird die laufende Sitzung also erneut authentifiziert. Daher der neue Zeitstempel im LastLogonDate.
"beim Herstellen einer neuen Sitzung" tritt ein
- wenn man sich interaktiv am Desktop anmeldet, lokal oder RDP
- wenn man über Netzwerk auf eine Ressource eines Servers zugreift und die letzte Sitzung dort bereits abgelaufen ist, z.B. Zugriff auf Exchange Postfach
Es ist also anzunehmen, dass diese Benutzer entweder Ihre PC's noch laufen haben und dort angemeldet sind, oder dass diese irgendwo getrennte RDP-Sitzungen am Laufen haben.
E.
Hi,
das hilft mir schon etwas weiter.
der Wert der User sieht so aus:
Alle User dort haben die Uhrzeit 00:06-00:08
Wie kann ich herausfinden welcher Task das macht?
Gibt es eine Richtlinie, dass nach einem bestimmten Passwort alter sich das Konto deaktiviert / auf einen bestimmten Wert zurücksetzt?
Gruß
das hilft mir schon etwas weiter.
der Wert der User sieht so aus:
Enabled = True
PasswordNeverExpires = False
PasswordExpired = True
Passwort LastSet =
LockedOut = False
Last Logon Date = 19.07.2019 00:07
PW Age = 43665Alle User dort haben die Uhrzeit 00:06-00:08
Wie kann ich herausfinden welcher Task das macht?
Gibt es eine Richtlinie, dass nach einem bestimmten Passwort alter sich das Konto deaktiviert / auf einen bestimmten Wert zurücksetzt?
Gruß
Habt Ihr einen TS im Einsatz?
Falls ja:
melden sich die Benutzer dort ab oder trennen sie bloß?
Es sei denn, er läuft "nur wenn Benutzer angemeldet", dann wäre das aber ein klares Indiz dafür, dass da irgendwo Sitzungen laufen.
Geld einzahlen oder abheben?
Falls ja:
melden sich die Benutzer dort ab oder trennen sie bloß?
Alle User dort haben die Uhrzeit 00:06-00:08
Alle Benutzer? Auch der Admin und sonstige Dienstkonten?Wie kann ich herausfinden welcher Task das macht?
Einen Task kannst Du auschließen, weil der ja eine neue Anmeldung (Sitzung) erfordern würde und PasswordExpired = True ist.Es sei denn, er läuft "nur wenn Benutzer angemeldet", dann wäre das aber ein klares Indiz dafür, dass da irgendwo Sitzungen laufen.
Gibt es eine Richtlinie, dass nach einem bestimmten Passwort alter sich das Konto deaktiviert
Nein.... sich das Konto .... auf einen bestimmten Wert zurücksetzt
Das Konto auf einen Wert?Geld einzahlen oder abheben?
Zitat von @emeriks:
Habt Ihr einen TS im Einsatz?
Falls ja:
melden sich die Benutzer dort ab oder trennen sie bloß?
Die User trennen sich meistens nur.Habt Ihr einen TS im Einsatz?
Falls ja:
melden sich die Benutzer dort ab oder trennen sie bloß?
Habe alle TS durchgeschaut, es sind keine Sitzungen mit den Usern offen.
Alle User dort haben die Uhrzeit 00:06-00:08
Alle Benutzer? Auch der Admin und sonstige Dienstkonten?Theoretisch würde es ja bedeuten, User meldet sich um 00:06 nachts an, um beim Passwortwechsel wieder den PC auszuschalten.
Ich verstehe nicht, wie man sich ohne PW Wechsel anmelden könnte (Last Logon Date).
Wie kann ich herausfinden welcher Task das macht?
Einen Task kannst Du auschließen, weil der ja eine neue Anmeldung (Sitzung) erfordern würde und PasswordExpired = True ist.Es sei denn, er läuft "nur wenn Benutzer angemeldet", dann wäre das aber ein klares Indiz dafür, dass da irgendwo Sitzungen laufen.
Gibt es eine Richtlinie, dass nach einem bestimmten Passwort alter sich das Konto deaktiviert
Nein.... sich das Konto .... auf einen bestimmten Wert zurücksetzt
Das Konto auf einen Wert?Geld einzahlen oder abheben?
Sollte sich das irgendwie erklären lassen, dass die 10 User sich einfach mit der Passwortrichtlinie zeitlich überschritten haben, kann ich damit leben und würde den Usern einfach ein Passwort setzen / sie deaktivieren.
Habe den Fehler gefunden.
der Wert LastLogonDate spuckt ein falsches Datum aus.
Der Timestamp LastLogon ist richtig - daher wird dieser Wert zur Kontrolle genommen und einfach per Excel als Datum angezeigt.
Danke für die Antworten.
der Wert LastLogonDate spuckt ein falsches Datum aus.
Der Timestamp LastLogon ist richtig - daher wird dieser Wert zur Kontrolle genommen und einfach per Excel als Datum angezeigt.
Danke für die Antworten.
