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!

Recommended Posts

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

Link to post

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.

  • Like 1
Link to post
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 to post

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 by SandyB
Link to post
  • 1 month later...

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 by Mr_Marple
Link to post
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 to post

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 to post
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 to post
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 to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...