Welcher Benutzer meldet sich auf welchem Rechner an

[StefanWe 14]

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.

[NorbertFe 2.069]

Wäre es nicht einfacher zu _definieren_, wo sich diese sensiblen Konten überhaupt anmelden _dürfen_?

[StefanWe 14]

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. 

[NorbertFe 2.069]

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

[Sunny61 809]

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

[daabm 1.366]

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.

[StefanWe 14]

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.

[SandyB 9]

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

[Mr_Marple 15]

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

[Dukel 455]

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.

[SandyB 9]

Man ist hier schnell im Bereich "Unzulässige Verhaltens- und Leistungskontrolle"

bearbeitet 10. Oktober 2020 von SandyB

[daabm 1.366]

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

[mwiederkehr 383]

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.

[Sunny61 809]

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.

[StefanWe 14]

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?