Jump to content

Welcher Benutzer meldet sich auf welchem Rechner an


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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.

Link zu diesem Kommentar
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. 

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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 von SandyB
Link zu diesem Kommentar
  • 1 Monat später...
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).

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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?

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...