Aktualisierung lastLogonTimestamp Problem/Kündigung

[Dr.Melzer 191]

Inhalt der Zitate aus der Gerichtsverhandlung von Dr.Melzer entfernt

Ich habe den Text des von dir zitierten Dokumentes entfernt. Wir sind ein technisches Forum und da sind juristische Dinge fehl am Platze, zumal wir auch keine Rechtsberatung machen dürfen.

[MichaelBY 0]

Ich habe den Text des von dir zitierten Dokumentes entfernt. Wir sind ein technisches Forum und da sind juristische Dinge fehl am Platze, zumal wir auch keine Rechtsberatung machen dürfen.

Waren keine Juristischen Dinge?! Das war die Stellungnahme des Outsourcing Providers... Fragt auch keiner nach Rechtsberatung, das macht der Anwalt. Ich bin einfach nur auf der Suche nach Gründen die zu einem Update des LLTS geführt haben könnten, wobei es natürlich hilfreich ist den komplett Fall zu kennen...

bearbeitet 10. November 2015 von MichaelBY

[blub 115]

Ich habe mir jetzt erst den ganzen Thread durchgelesen.  :shock: :shock:

Eine fristlose Kündigung eines Mitarbeiters wegen absolut Nichts! Toll, dass du dich der Sache angenommen hast! :thumb1:

[NorbertFe 1.798]

Naja zumindest "nichts" auf technischer Ebene. ;) Was drum herum vorfällt weiß man nicht und ist normalerweise nicht rechtlich standhaltend, also kann man auch mal was "konstruieren". :|

Ich mutmaße aber nur.

[Dr.Melzer 191]

Ich bin einfach nur auf der Suche nach Gründen die zu einem Update des LLTS geführt haben könnten,

Dann bitte das als Aufgabenstellung belassen und hier die technische Seite hinterfragen

 

wobei es natürlich hilfreich ist den komplett Fall zu kennen...

Um eine technische frage zu beantworten sind IMHO keine Details der Gerichtsakten notwendig, sondern das Wissen um die technischen Hintergründe. Die Frage ist ja als solche erst mal unabhängig von eurem juristischen Problem.

 

IMHO lenkt zu viel Information außen rum ab und verdeckt möglicherweise den Blick auf etwas das ihr bisher übersehen habt.

[MichaelBY 0]

Hab mal eine Zusammenfassung der bis jetzt gefundenen Punkte erstellt:

 

 

1. Provider Analyse

Die Provider Analyse sagt bereits aus das es keine Logon/Logoff Events gab. Die Firma hat dies falsch interpretiert da sie keinen Profi zur Hand hatte der den Bericht verstanden hat.

„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“

Siehe auch Beweise unten. Für die Auswertung des tatsächlichen letzten Logins ist nur „LastLogon“ auf allen Domain Controller auszuwerten, da nur dieser Wert die tatsächlichen „echten“ Logins speichert. Wie vom Provider geschildert sind diese nicht vorhanden. Somit kann die Aktualisierung des LastLogonTimestamps nur durch andere Aktionen wie in den nächsten Punkten beschrieben erfolgt sein. à Kein Login!

 

2. LastLogonTimeStamp ist nicht richtig von der Uhrzeit:
http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

Microsoft empfiehlt diesen Wert nicht zu verwenden denn er kann 7-14 Tage falsch sein oder sogar durch andere Anfragen erstellt werden. Empfohlen wird die Security Logs der Server zu verwenden. Dies sind die Logon/Logoff Events, die laut dem Bericht des Providers leer sind. Das deutet darauf hin dass gar kein Login erfolgt ist. Eine Gegenprobe wäre zum Beispiel gewesen andere Accounts die auch gesperrt sind zu überprüfen ob die ebenso ein Update des LLTS haben.. (nicht erfolgt)

 

3. LastLogonTimeStamp wurde anderweitig aktualisiert:

Interactive, Network, and Service logons updaten den lastLogontimeStamp, dies kann zB. Durch Rechte(Access-Checks), Gruppen Mitgliedschafts-Abfragen oder Trust-Aktionen passieren.

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

Service-for-User-to-Self kann den LLTS auch aktualisieren. ZB. Bei der Abfrage von Gruppen Mitgliedschaften. In diesem Artikel ist genau beschrieben dass das häufig zu Sicherheits-Bedenken führt weil Accounts als „benutzt“ markiert sind obwohl sie das nicht waren.

 

4. LastLogonTimeStamp wurde durch ein anderes System aktualisiert:

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

lastlogontimestamp zeigt nicht dass ein User aktiv war zu der Zeit, sondern zeigt nur das der Account (wenn der Eintrag älter ist) schon länger nicht mehr benutzt wurde. Dieser Wert ist somit nur gut um alte Accounts aus dem System zu erkennen und zu bereinigen.

https://support.microsoft.com/en-us/kb/939899

 

In dem geschilderten Fall wurde der LLTS durch einen SharePoint Server aktualisiert. (Hat diese Firma auch), ich könnte mir auch vorstellen dass ein vorhandenes Identity Management System den Eintrag aktualisiert hat.

bearbeitet 12. November 2015 von MichaelBY

[daabm 1.183]

[OT]Irgendwas davon war glaub von mir im Technet gepostet... Ich find solche Themenmischungen in zwei Foren irgendwie nicht gut - da gehen die Credits für hilfreiche Beiträge etwas verloren.

[MichaelBY 0]

[OT]Irgendwas davon war glaub von mir im Technet gepostet... Ich find solche Themenmischungen in zwei Foren irgendwie nicht gut - da gehen die Credits für hilfreiche Beiträge etwas verloren.

 

ja, immer einfach gesagt, aber es sind halt in beiden Foren auch unterschiedliche Leute unterwegs. Ist leider ein sehr wichtiges Thema, hätte ich den "richtigen" gefunden hätte ich auch gerne für eine vollumfängliche "Beratung" bezahlt...

[daabm 1.183]

Nee, sind in beiden Foren meistens die gleichen, nur unterschiedliche Nicknames :)

[Doso 77]

Wir authentifizieren bei uns eine Anwendung, die macht auth per LDAP gegenüber AD 2008r2. Paar Tausend Nutzer pro Tag. Auch hier haben wir schon "Merkwürdigkeiten" beobachtet. Das Attribut macht halt nicht das, was man evtl. von ihm erwartet.

 

Deswegen eine Kündigung aussprechen ist halt einfach ***isch.

bearbeitet 15. November 2015 von Doso

[Canni 11]

Da kann man sich nur glücklich schätzen, nicht in so einer Firma zu arbeiten. Tut mir leid, dass Du mit so einem Mist nun Arbeit hast. In so einer Firma ist ja quasi niemand sicher, morgen nicht der Nächste zu sein (gerade in der IT), wenn auf Grundlage solcher Indizien (die gerichtlich nicht haltbar sein werden) Kündigungen ausgesprochen werden. Klar ist aber natürlich auch, dass der gehandhabte Prozess so auch nicht revisionssicher war/ist. Der betroffene Account wäre zu sperren gewesen und/oder das Ablaufdatum entsprechend zu setzen; das ursprüngliche User-Kennwort hat so zu bleiben, wie es war. So eine Vorgehensweise ist natürlich immer nur so gut, wie auch das Logging, das auf der anderen Seite dazugehört.

[MichaelBY 0]

Hallo nochmal,

gibt es jemand der dazu nochmal eine fundierte Aussage treffen kann? Das Thema ist leider immer noch nicht durchgestanden und wieder aktuell.

Die MS Dokumentation ist leider nicht 100% aussagekräftig, es ist immer nur die Rede von "könnte" durch dieses und jenes aktualisiert worden sein. Jedoch eine klare Aussage wie etwa: Das Attribut darf keines Falls für solch eine Analyse verwendet werden, fehlt mir nach wie vor.

 

Vielen Dank im Voraus

[Doso 77]

Wenn du da was konkretes brauchst wirst du dich an den Hersteller wenden müssen. Ist wohl eher die Frage ob denn jemand das Gegenteil beweisen kann.

[NorbertFe 1.798]

GEnau den selben Rat hat er ja auch im TechNet Forum bekommen. ;) Ich denke viel mehr wird man nicht beitragen können.

[MichaelBY 0]

Jep, Danke nochmals ;) 

ihr habt wohl Recht, nur man versucht halt noch alle Eventualitäten vorher zu prüfen. Die Beauftragung des Herstellers (aufgrund der Kosten) kann nur durchs Gericht erfolgen.

 

Die rechtlichen Themen will ich nun nicht mehr aufwärmen, aber es ist leider dabei nicht so einfach schwarz/weiß oder 0/1 zu sehen wie wenn wir uns um IT-Themen kümmern müssen.