StefanWe 14 Geschrieben 26. August 2020 Melden Teilen Geschrieben 26. August 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. Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 26. August 2020 Melden Teilen Geschrieben 26. August 2020 Wäre es nicht einfacher zu _definieren_, wo sich diese sensiblen Konten überhaupt anmelden _dürfen_? Zitieren Link zu diesem Kommentar
StefanWe 14 Geschrieben 26. August 2020 Autor Melden Teilen Geschrieben 26. August 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. Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 26. August 2020 Melden Teilen Geschrieben 26. August 2020 (bearbeitet) Was ist denn ein sensible Account? Das wird er ja aus einem Grund sein und dann gibts auch entsprechende Anforderungen, oder? bearbeitet 26. August 2020 von NorbertFe Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 26. August 2020 Melden Teilen Geschrieben 26. August 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. :) Zitieren Link zu diesem Kommentar
daabm 1.348 Geschrieben 26. August 2020 Melden Teilen Geschrieben 26. August 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 Zitieren Link zu diesem Kommentar
StefanWe 14 Geschrieben 27. August 2020 Autor Melden Teilen Geschrieben 27. August 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. Zitieren Link zu diesem Kommentar
SandyB 9 Geschrieben 27. August 2020 Melden Teilen Geschrieben 27. August 2020 (bearbeitet) 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 bearbeitet 27. August 2020 von SandyB Zitieren Link zu diesem Kommentar
Mr_Marple 15 Geschrieben 9. Oktober 2020 Melden Teilen Geschrieben 9. Oktober 2020 (bearbeitet) 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. bearbeitet 9. Oktober 2020 von Mr_Marple Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 9. Oktober 2020 Melden Teilen Geschrieben 9. Oktober 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. Zitieren Link zu diesem Kommentar
SandyB 9 Geschrieben 10. Oktober 2020 Melden Teilen Geschrieben 10. Oktober 2020 (bearbeitet) Man ist hier schnell im Bereich "Unzulässige Verhaltens- und Leistungskontrolle" bearbeitet 10. Oktober 2020 von SandyB Zitieren Link zu diesem Kommentar
daabm 1.348 Geschrieben 11. Oktober 2020 Melden Teilen Geschrieben 11. Oktober 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). Zitieren Link zu diesem Kommentar
mwiederkehr 373 Geschrieben 12. Oktober 2020 Melden Teilen Geschrieben 12. Oktober 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. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 12. Oktober 2020 Melden Teilen Geschrieben 12. Oktober 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. Zitieren Link zu diesem Kommentar
StefanWe 14 Geschrieben 12. Oktober 2020 Autor Melden Teilen Geschrieben 12. Oktober 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? Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.