StefanWe 14 Posted August 26, 2020 Report Posted August 26, 2020 Hallo, wir möchten gerne für sensible Konten protokollieren, auf welchen Workstations / Servern diese sich anmelden. Dafür haben wir auf den Domänencontrollern die Advanced Audit Policy aktiviert, das erfolgreiche und fehlgeschlagene Logon Events protokolliert werden. Leider taucht hier aber nicht der Workstation Name auf. Wisst ihr, wie ich den Workstationnamen ebenfalls mit rausbekomme? Theoretisch müsste der Domänencontroller ja sehen, von welchem Client das Kerberos Token angefragt wird. Quote
NorbertFe 2,138 Posted August 26, 2020 Report Posted August 26, 2020 Wäre es nicht einfacher zu _definieren_, wo sich diese sensiblen Konten überhaupt anmelden _dürfen_? Quote
StefanWe 14 Posted August 26, 2020 Author Report Posted August 26, 2020 vor einer Stunde schrieb NorbertFe: Wäre es nicht einfacher zu _definieren_, wo sich diese sensiblen Konten überhaupt anmelden _dürfen_? Der Ansatz ist nachvollziehbar. Allerdings wissen wir nicht genau, auf welchen Systemen der Account zugreift, bzw. Zugreifen muss. wie nennt man das, historisch gewachsen. ps Eventid 4624 beinhaltet leider nicht die Workstation. Quote
NorbertFe 2,138 Posted August 26, 2020 Report Posted August 26, 2020 (edited) Was ist denn ein sensible Account? Das wird er ja aus einem Grund sein und dann gibts auch entsprechende Anforderungen, oder? Edited August 26, 2020 by NorbertFe Quote
Sunny61 816 Posted August 26, 2020 Report Posted August 26, 2020 vor 3 Stunden schrieb StefanWe: Allerdings wissen wir nicht genau, auf welchen Systemen der Account zugreift, bzw. Zugreifen muss. Wenn Du nur die freigibst, auf die er *jetzt* zugreifen muss, wirst Du es sicherlich als Erster erfahren, wenn er sich an einer Maschine anmelden möchte, aber Du es nicht zugelassen hast. :) Quote
daabm 1,377 Posted August 26, 2020 Report Posted August 26, 2020 Siehe Hinweis von @Sunny61, das würde ich als erstes umsetzen. Und "Lokale Anmeldung" an Clients läßt sich in den Eventlogs von Domain Controllern NICHT überwachen, das muß clientseitig passieren. Einfachstes Beispiel für "warum geht das nicht": Cached Credentials. 1 Quote
StefanWe 14 Posted August 27, 2020 Author Report Posted August 27, 2020 vor 9 Stunden schrieb daabm: Siehe Hinweis von @Sunny61, das würde ich als erstes umsetzen. Und "Lokale Anmeldung" an Clients läßt sich in den Eventlogs von Domain Controllern NICHT überwachen, das muß clientseitig passieren. Einfachstes Beispiel für "warum geht das nicht": Cached Credentials. Ok danke. Ich habs befürchtet. Quote
SandyB 9 Posted August 27, 2020 Report Posted August 27, 2020 (edited) Wenn es eine überschaubare Menge an Clients ist und du einen gemeinsamen ClientAdmin besitzt, kannst du quser bzw. dieses Script zentral schedulen: https://gallery.technet.microsoft.com/scriptcenter/Get-LoggedOnUser-Gathers-7cbe93ea .\Get-LoggedOnUser.ps1 -ComputerName server01,server02,client03 oder auch 'server01','server02','client3' | .\Get-LoggedOnUser.ps1 Edited August 27, 2020 by SandyB Quote
Mr_Marple 15 Posted October 9, 2020 Report Posted October 9, 2020 (edited) Ist ja schon eine Weile her, aber ich würde das einfach über ein Login Skript machen. echo %date% %time% %username% %computername% >> \\dc1.domain.local\sysvol\domain.local\login\txt.txt DC1 deshalb, damit es nur eine Version gibt und sich nichts drüber repliziert. Edited October 9, 2020 by Mr_Marple Quote
Dukel 459 Posted October 9, 2020 Report Posted October 9, 2020 Wieso auf den DC und nicht z.B. einen Fileserver? Man sollte dabei auf die Rechte aufpassen. Sonst können die Mitarbeiter die Daten anderer Kollegen lesen. Quote
SandyB 9 Posted October 10, 2020 Report Posted October 10, 2020 (edited) Man ist hier schnell im Bereich "Unzulässige Verhaltens- und Leistungskontrolle" Edited October 10, 2020 by SandyB Quote
daabm 1,377 Posted October 11, 2020 Report Posted October 11, 2020 Am 9.10.2020 um 17:24 schrieb Mr_Marple: Ist ja schon eine Weile her, aber ich würde das einfach über ein Login Skript machen. echo %date% %time% %username% %computername% >> \\dc1.domain.local\sysvol\domain.local\login\txt.txt DC1 deshalb, damit es nur eine Version gibt und sich nichts drüber repliziert. Abgesehen vom Problem der Verhaltens- und Leistungskontrolle, das vorher unbedingt (!) geklärt werden muß: So funktioniert das garantiert nicht, weil alle "gleichzeitig" in das gleiche File schreiben. Und warum das auf Sysvol liegen sollte, weißt auch nur Du. Entweder gleich richtig (also in eine Datenbank) oder wenigstens in ein individuelles File pro User und/oder pro Client (in der Annahme, daß sich ein User immer nur zu einer Zeit wo anmeldet und daß sich auf einem Client immer nur ein User gleichzeitig anmeldet). Quote
mwiederkehr 387 Posted October 12, 2020 Report Posted October 12, 2020 Vor einigen Jahren habe ich so etwas mal mit .NET und SQLite umgesetzt: per Anmeldescript wurden Anmeldungen in der Datenbank protokolliert und per Abmeldescript auch die Abmeldungen. Mit einer Abfrage konnte man dann feststellen, ob User XY zur Zeit eingeloggt und ist falls ja, an welchem Rechner. Es ging da um wechselnde Arbeitsplätze, aber ohne wechselnde Rufnummern. Heutzutage liesse sich das recht einfach mittels PowerShell und SQLite umsetzen. Da die Benutzer Zugriff auf die Datenbank haben müssen, lässt sich nicht verhindern, dass sie diese auslesen. Will man die Daten schützen, braucht man einen (einfachen) Web Service dazwischen, welcher die Daten einträgt. Dafür reicht dann im Anmeldescript ein Aufruf von Invoke-WebRequest mit https://srv/log?hostname=x&username=y&action=logon. Quote
Sunny61 816 Posted October 12, 2020 Report Posted October 12, 2020 vor 32 Minuten schrieb mwiederkehr: Da die Benutzer Zugriff auf die Datenbank haben müssen, lässt sich nicht verhindern, dass sie diese auslesen. Doch, lässt sich verhindern. Pack das Script auf dem SQL Server in eine Stored Procedure und gib dem User die Rechte auf die SP. Im Script wird nur die SP mit Parametern aufgerufen, das reicht. Die SP macht den Rest, der User hat braucht keine Rechte auf die Tabelle. Quote
StefanWe 14 Posted October 12, 2020 Author Report Posted October 12, 2020 vor einer Stunde schrieb mwiederkehr: Will man die Daten schützen, braucht man einen (einfachen) Web Service dazwischen, welcher die Daten einträgt. Dafür reicht dann im Anmeldescript ein Aufruf von Invoke-WebRequest mit https://srv/log?hostname=x&username=y&action=logon. Ist vielleicht etwas Off topic dazu, aber womit würdest du solch einen einfaches Webservice erstellen? Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.