MichaelBY

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.

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

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...

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.

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...

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.

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 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? 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

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?

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. Kannst du mehr dazu erklären, oder verraten wo so etwas geschrieben steht?

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 Anmeldung mit dem richtigen Passwort Bei falschem PW gäbe es den oben erwähnten Eintrag „badPasswordTime“ Hinweis, dass ein Passwortwechsel erfolgen muss Wird hier Cancel gedrückt, erfolgt keine Änderung am Benutzerkonto. Dialogfeld zur Eingabe eines neuen PW Wird hier Cancel gedrückt, erfolgt keine Änderung am Benutzerkonto. 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. 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