Aktualisierung lastLogonTimestamp Problem/Kündigung

[MichaelBY 0]

Hallo zusammen,

 

habe folgendes Problem und bräuchte eure Unterstützung:

Mitarbeiter „X“ kündigt verärgert an einem Tag gegen Ende Juni direkt beim CEO.
Mitarbeiter „X“ war Mitglied der Geschäftsführung. Darauf hin beauftragt der CEO, Firmenanwalt und Compliance Officer den Mitarbeiter „Y“ mit der Sperrung des Accounts.
Mitarbeiter „Y“ ist IT-Leiter und nimmt die Sperre durch Reset des Passworts im AD und setzen der Option „User must change password at next logon“ vor.
Dies war gängige Praxis in der Firma, Account Disable Funktion aufgrund Outsourcing nicht möglich.

 

Ein Monat später wird in den Logdateien des Domain Controllers folgendes gefunden:

.lastLogonTimestamp des Accounts von Mitarbeiter X wurde aktualisiert (ca. 1 Monat nach Sperrung).

Das Flag „Zwang das Passwort zu ändern nach erfolgreichen Login“ wurde nicht gelöscht, somit wurde nach dem Login mit dem gültigen PW kein neues PW vergeben und der Login war nicht vollständig

Es gibt keinen Eintrag „badPasswordTime“ somit keine Eingabe eines falschen PW.

 

Mitarbeiter Y wird nun vorgeworfen er hätte sich mit dem Account des Mitarbeiter X eingeloggt. Mitarbeiter Y weiß aber das PW selbst nicht da er es sich nicht gemerkt hat nach dem Reset.

Mitarbeiter Y wird daraufhin fristlos entlassen.

 

Hat jemand von euch eine Idee wie es zur Aktualisierung des „.lastLogonTimestamp“ gekommen sein könnte?

 

Ich habe selbst schon ein wenig recherchiert und einen Bug des OWA gefunden bei dem der Login Token noch nach Monaten und auch nach PW Reset noch gültig war. Aber richtige Beweise und eine Erklärung eines Profis die vor Gericht vorgetragen werden könnte fehlt mir nach wie vor.

 

Ich wäre für Hilfe sehr dankbar, da es um Erhalt des Arbeitsplatzes von Mitarbeiter Y bzw. eine Abfindung für diesen geht. (gern auch per PM)

 

 

Darstellung voller Fall:

 

Datenauskunft Anfrage vom 2x.08.2015

 

Der aktuelle Stand der Erkenntnisse:

 

Am 2x.06.2015 zwischen 11 und 13 Uhr veranlasste unsere Geschäftsleitung eine Zurücksetzung des Passwortes unseres Mitarbeiters Hr. X

>>Dies ist im Eventlog des xxxxDC01 protokolliert. Erfolgt durch adm-Y um 12:13uhr

 

 

Heute stellten wir über das Active Directory fest dass am 2x.07.2015 um 11:30 Uhr ein Zugriff auf den Account erfolgte (Attribut: lastlogonTimestamp)

>>Auch diese Angabe ist nachvollziehbar im Konto des Users.

 

Verlauf aller Passwortänderungen für den Account X ab dem 2x.06.2015 mit Angabe von Datum und Uhrzeit:
>>Auf dem schreibenden AD Kontrollern sind keine neueren Änderungen protokolliert.

 

Welche Applikationen wurden gestartet und welche Aktionen wurden im Account ausgeführt? Gibt es die Möglichkeit einer Nachverfolgung?
>>Hierzu können mangels entsprechender Log-Dateien keine Aussagen gemacht werden.

 

 

Für die Auswertung der Ereignisse wurden die Security-Eventlogs der schreibenden Domänenkontroller gesichert und der Account X exportiert. Logon/Logoff Events stehen nicht zur Verfügung

 

Bei der Rücksetzung des Accounts am 2x.06. wurde ein neues Passwort vergeben und die Option „User must change password at next Logon“ gesetzt. Das ergibt sich aus der Folge der Events 4738, 4724 und wieder 4738.

Letzterer zeigt die Änderung „Password Last Set: <never>“, die mit der o.g. Option einhergeht und anderenfalls fehlen würde.

 

Am 0x.07.2015 um 17:07 ist eine (letztmalige) Anmeldung mit falschem Passwort erfolgt. Siehe Userkonto Attribut „BadPasswordTime“.

 

Die zentrale Frage ist, was am 2x.07.2015 geschehen ist. Der „lastLogonTimestamp“ wurde aktualisiert, jedoch nicht der Zwang zum Passwort ändern zurückgesetzt. Eine vollständige Anmeldung ist wegen der gesetzten Option nur mit Erneuerung des Passwortes möglich, wodurch aber eben diese Zwangsoption gelöscht wird.

Ein erneutes manuelles konfigurieren dieser Option oder ein erneutes zurücksetzten des Passwortes hätte neue Eventlog Einträge und einen neueren „modified“ Eintrag im Konto zur Folge gehabt. Beides ist nicht registriert.

 

Durch Tests mit einem anderen Account wurde versucht, die Situation nachzustellen und als Ergebnis ein Konto zu erzeugen, dass die gleiche Kombination von Werten hat wie bei „X“ vorgefunden. Erschwert wurde die Prüfung durch das Vorhandensein eines RODC am Standort ZZZZ und die Art und Weise der Implementierung des Attributes „LastLogonTimestamp“ durch Microsoft.

 

Folgend der Ablauf des Logins

1. Anmeldung mit dem richtigen Passwort
   Bei falschem PW gäbe es den oben erwähnten Eintrag „badPasswordTime“
2. Hinweis, dass ein Passwortwechsel erfolgen muss
   Wird hier Cancel gedrückt, erfolgt keine Änderung am Benutzerkonto.
3. Dialogfeld zur Eingabe eines neuen PW
   Wird hier Cancel gedrückt, erfolgt keine Änderung am Benutzerkonto.
4. Ein den Richtlinien entsprechendes PW erzeugt eine Bestätigung und der User ist eingeloggt. Im Konto wird LastLogonTimestamp aktualisiert, aber auch der Änderungszwang gelöscht.
5. Das neue PW entspricht nicht den Richtlinien (zu kurz, schon benutzt, etc.)
   Ein entsprechender Hinweis erscheint. Hier kann man wieder zu c) zurückkehren.
   oder die Anmeldung abbrechen. WICHTIG: In diesem Falle wird das auf das Konto zugegriffen und der LastLogonTimestamp aktualisiert, jedoch ist das Passwort noch nicht geändert worden und der Zwang dazu bleibt bestehen.

 

Durch genau diesen Ablauf wird das Konto in genau dem Zustand verbleiben, der vorgefunden wurde.
Andere Möglichkeiten konnten nicht ermittelt werden. Jede weitere Änderung hätte neue Eventlog Einträge und/oder einen aktualisierten Userkonto Timestamp (object_modified, Attribut „whenChanged“) zur Folge gehabt.

 

Da abschließend keine vollständige Anmeldung stattgefunden hat, sind nach meinem Dafürhalten mit diesem Account auch keine weiteren Aktionen durchgeführt worden.

 

2x.08.2015 Admin von Outsourcing Provider ZZZZ

bearbeitet 10. November 2015 von MichaelBY

[zahni 554]

Vielleicht  helfen die neueren  Logon Informations weiter:

 

https://technet.microsoft.com/en-us/library/dd446680(v=ws.10).aspx

 

Normalerweise sollten solche Konten aber  gesperrt ("deaktiviert") werden.

[NorbertFe 2.062]

Oder zumindest Ablauf definieren. Aber im Endeffekt dürfte ein arbeitsrechtsanwalt wohl der bessere Partner im Fall y sein.

bearbeitet 9. November 2015 von NorbertFe

[daabm 1.366]

lastLogonTimeStamp aktualisiert sich "unberechenbar" und ist kein verwertbares Merkmal...

[MichaelBY 0]

Oder zumindest Ablauf definieren. Aber im Endeffekt dürfte ein arbeitsrechtsanwalt wohl der bessere Partner im Fall y sein.

bereits alles am Laufen und Gerichtstermine angesetzt.... Nur es geht immer noch darum zu beweisen dass gar nix passiert ist oder eine Argumentation zu haben wie es zu dem Eintrag kam...

 

Das die Art der Account Sperrung nicht perfekt war ist klar. Nur leider lässt der Outsourcing Provider das Deactivate Feature nicht zu. Normale Account Löschungen laufen über ein Identity Management System. Bei Ad Hoc Themen wie in diesem Fall wird leider der PW-Reset genutzt.

 

 

lastLogonTimeStamp aktualisiert sich "unberechenbar" und ist kein verwertbares Merkmal...

 

Kannst du mehr dazu erklären, oder verraten wo so etwas geschrieben steht?

bearbeitet 9. November 2015 von MichaelBY

[NorbertFe 2.062]

Google? ;)

http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

Intended Use

 

It is important to note that the intended purpose of the lastLogontimeStamp attribute to help identify inactive computer and user accounts. The lastLogon attribute is not designed to provide real time logon information. With default settings in place the lastLogontimeStamp will be 9-14 days behind the current date.

 

If you are looking for more “real-time” logon tracking you will need to query the Security Event log on your DC’s for the desired logon events i.e. 528 –Windows XP\2003 and earlier or 4624 Windows Vista\2008 . See this blog post by Eric Fitzgerald for more info. (I think he knows something about auditing)

 

IMO your best bet for near real-time data is to use an event log collection service to gather all domain controller security event logs to a centralized database. You can then query a single database for the desired logon events. Microsoft’s solution for security event log collection is Audit Collection Services. There are many 3rd party solutions as well.

Ich drück dir die Daumen und hoffe es hilft dir.

 

Bye

Norbert

[MichaelBY 0]

hab hier was gefunden:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/94a3e405-0d65-41a6-8508-2619f01871cc/lastlogontimestamp-what-updates-this-attribute?forum=winserverDS

Dort wurde der LastLogonTimeStamp aktualisiert obwohl Passwörter abgelaufen waren... also eigentlich genau der Fall? Das PW war zurückgesetzt und keiner kannte es. Trotzdem wurde der LastLogonTimeStamp aktualisiert...

Macht das Sinn eurer Meinung nach?

[Sunny61 807]

Lt. den hiesigen Boardregeln darfst Du auch auf das Crossposting in den Technet Foren hinweisen. No. 19 suchst Du. http://www.mcseboard.de/topic/191452-mcseboardde-regeln-nutzungsbedingungen/

[NilsK 2.958]

Moin,

 

abgesehen davon, dass wir hier keine Rechtsberatung machen dürfen, kann ich mir nicht vorstellen, dass ein Arbeitsgericht ein so dünnes Indiz wie das genannte als Kündigungsgrund akzeptiert. Die Beweiskraft ist offensichtlich nahe Null. Sogar das verlässlichere Attribut lastLogon würde nicht ernsthaft den Schulss zulassen, dass Mitarbeiter Y sich angemeldet hat.

 

Gruß, Nils

[blub 115]

Hi,

Das Phänomen des sich aktualisierenden LastLogonTimestamps bei StaleAccounts kommt vom Service-for-User-to-Self or, “S4u2Self,”

 

see 

http://blogs.technet.com/b/askpfeplat/archive/2014/04/14/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self.aspx

Das Verhalten hat mich auch schon mal hochgejagt :-), ist aber "by design"

blub

[MichaelBY 0]

Lt. den hiesigen Boardregeln darfst Du auch auf das Crossposting in den Technet Foren hinweisen. No. 19 suchst Du. http://www.mcseboard.de/topic/191452-mcseboardde-regeln-nutzungsbedingungen/

Danke für den Hinweis.

 

hab auch im TN gepostet unter: 

https://social.technet.microsoft.com/Forums/de-DE/64889d0d-f34b-4e69-b188-5d39c9cb4471/aktualisierung-lastlogontimestamp-problem?forum=active_directoryde

Hi,

Das Phänomen des sich aktualisierenden LastLogonTimestamps bei StaleAccounts kommt vom Service-for-User-to-Self or, “S4u2Self,”

 

see 

http://blogs.technet.com/b/askpfeplat/archive/2014/04/14/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self.aspx

Das Verhalten hat mich auch schon mal hochgejagt :-), ist aber "by design"

blub

 

Hi Blub, das hört sich auch gut an, hab mir den Artikel mal durchgelesen. So tief bin ich am im AD nicht drin das ich das verstehe. Könnte zum Beispiel ein Identity Management System den S4u2Self getätigt haben?

 

 

 

Moin,

 

abgesehen davon, dass wir hier keine Rechtsberatung machen dürfen, kann ich mir nicht vorstellen, dass ein Arbeitsgericht ein so dünnes Indiz wie das genannte als Kündigungsgrund akzeptiert. Die Beweiskraft ist offensichtlich nahe Null. Sogar das verlässlichere Attribut lastLogon würde nicht ernsthaft den Schulss zulassen, dass Mitarbeiter Y sich angemeldet hat.

 

Gruß, Nils

 

Hallo Nils,

naja leider nicht ganz so einfach... 1. Verhandlung ging mit einem später nicht akzeptierten Vergleich aus und nun steht die große Nummer an. Klar ist es sehr dünn, aber darauf dass die Logs eventuell gar nicht richtig sind kam ich am Anfang schon, nur jetzt finden sich immer mehr Hinweise darauf. Es muss einfach genug Beweise geben die das zeigen dann wirds einfacher.

 

-----------------------------------------------

Inhalt der Zitate aus der Gerichtsverhandlung von Dr.Melzer entfernt

bearbeitet 10. November 2015 von Dr.Melzer

[blub 115]

Lt. Artikel wird der LastLogonTimestamp aktualisiert, wenn irgendjemand/ etwas einen Accesscheck z.b. auf einem Fileserver durchführt oder die GroupMembership des Accounts prüft. Auch durch bidirektionale Trusts kann der LLTS aktualisiert werden.

 

Der Account müsste nicht nur gesperrt, sondern sauber entrechtet wird. d.h. aus allen Berechtigungs-Gruppen entfernt wird.

[MichaelBY 0]

Lt. Artikel wird der LastLogonTimestamp aktualisiert, wenn irgendjemand/ etwas einen Accesscheck z.b. auf einem Fileserver durchführt oder die GroupMembership des Accounts prüft. Auch durch bidirektionale Trusts kann der LLTS aktualisiert werden.

 

Die Lösung besteht darin, dass der Account nicht nur gesperrt, sondern sauber entrechtet wird. d.h. aus allen Berechtigungs-Gruppen entfernt wird

Danke,

Problem hierbei, der Account sollte ja erhalten bleiben da der Mitarbeiter X eventuell zurück kommen sollte bzw. falls andere Sachen nachgewiesen worden wären für den Mitarbeiter X dessen Account überprüft und ausgewertet werden sollte. Aber wie man nen Account ordentlich schließt und keine Möglichkeiten mehr zum Login gibt ist mir klar, dass das hier falsch lief in diesem Sinne.

[NorbertFe 2.062]

Deswegen "ablaufen" oder "deaktivieren". Beide Varianten führen dazu, dass eine Anmeldung gar nicht möglich wäre.

[blub 115]

In den comments des Artikels habe ich noch diesen PS-Test gefunden

 

new-object system.security.principal.windowsidentity("username")

probier doch mal, ob sich LLTS updated