TrackLoginEvents
VBScript und 64Bit !
Viele 32bit COM-Objekte lassen sich auf einem 64bit System nur
instanzieren, wenn die 32bit Version von CSCRIPT/WSCRIPT genutzt wird,
welcher unter C:\Windows\SysWOW64\cscript.exe liegt.
Was machen meine User ist nur eine Frage in einem Netzwerk. Viel drängender sind Fragen, wie man Eindringlinge erkennt oder wie man Zugriffe nachverfolgen kann, die ja auf vielen Servern und Systemen passieren können. Allerdings kann ich hier kein komplettes "Auditsystem" liefern, welches Revisionssicher und fälschungssicher wäre. Das Skript TrackLoginEvents ist aus der Notwendigkeit entstanden, zu Erfahren, welche Accounts sich wo wie anmelden. Das ist z.B. erforderlich, wenn man ein Dienstkennwort ändern möchte und eigentlich nicht genau weiß, wo es denn überall eingesetzt wird. Das Skript DumpServiceAccounts hilft bei Dienstkonten schon gut aus, aber übersieht doch einige andere Anmeldedaten, die in den Tiefen von Systemen versteckt sind.
Mit TrackLoginEvents versuche ich auf Domain Controllern die Anmeldungen zu erhalten, um in der ersten Stufe eben eine Zuordnung von Anmeldungen zu Clients machen zu können. Dafür gibt es mehrere legitime Gründe, z.B.:
- Fehlerhafte Anmeldungen
Es ist schon wichtig, welche Anmeldungen fehlschlagen. Das können einfache Tippfehler von Anwendern sein aber auch eine Fehlkonfiguration von Dienstkonto oder Einbruchsversuche (Besonders bei Häufung). Aber auch Computer, die nicht mehr "richtig" in der Domäne sind (z.B.: Restore eines Image) , fallen hier auf. - Erfolgreiche Anmeldungen
Wenn das Security Log die Daten von vielen Wochen enthält, dann kann man eine sehr vollständige Liste erstellen, welches Konto sich auf welchen Systemen anmeldet. Das hilft z.B.: die Verwendung von Dienstkonten zu überwachen oder auch nachzuvollziehen wo sich ein Anwender anmeldet, um die Systeme bei einer Migration (ADMT) bei den Profilen zu berücksichtigen.
Sicher ist das Skript erst eine Grundversion, die man um weitere Events (z.B. Account Locked out) erweitern kann und je nach Event sogar eine Eskalation (z.B. Mail senden) anstoßen kann. Es ist immer von Vorteil, wenn der Helpdesk schon vor dem Anruf des Anwender schon das Problem kennt und nicht erst lange suchen muss. Der Helpdesk könnte ja auch aktiv den Anwender anrufen.
Da mit diesem Skript in Grenzen sogar Aktivitäten von Benutzern aufgezeichnet werden könnten, weise ich vorsorglich auf Datenschutz und Mitbestimmungsrichtlinien hin.
Logging aktivieren
Ehe Sie etwas auswerten, muss man Windows dazu überreden, auch etwas zu protokollieren. Das erfolgt am einfachsten in der "Default Domain Controllers Policy". Hier sind die beiden relevanten Einträge "Anmeldeversuche überwachen" und "Anmeldeereignisse überwachen".
Für beide Einstellungen können Sie konfigurieren, ob nur erfolgreiche, fehlerhafte oder beide Vorgänge protokolliert werden sollen. Etwas verwirrend ist natürlich die Bezeichnung und damit die Frage, was denn nun zu aktivieren ist.
- Anmeldeereignisse überwachen
Hiermit werden die Anmeldungen auf der Maschine protokolliert, auf der die Einstellung aktiv ist. Dies hat aber keinen Einfluss auf die Domain Controller. Ein Zugriff auf einen Mitgliedsserver wird also hier nur im Eventlog des Mitgliedsserver selbst aufgeschrieben. Da dies aber auch für die "Fileserverfunktion" (NETLOGON/SYSVOL) eines Domain Controllers gilt, erwischen Sie so schon sehr viele "normale" Anwender. - Anmeldeversuche überwachen
Diese Events erscheinen nicht im Eventlog des Servers, auf den der Anwender zugreift, sondern nur auf dem Domain Controller, welcher den Zugriff autorisiert, z.B. indem er ein Kerberos Ticket ausstellt oder der Memberserver die Anmeldung beim Domain Controller überprüft.
Danach landen im Eventlog jede Menge Events.
Die Beschränkung der Überwachung auf ausgewählte Server ist für den Server zwar hinreichend, aber liefert kein Gesamtbild. Selbst die Protokollierung auf dem DC liefert keinen vollständigen aber sehr umfangreichen Überblick über Anmeldungen im Netzwerk. Für eine komplette Lösung müssten alle Security Events aller Server an einer zentralen Stelle konsolidiert werden.
Zwei Dinge sollten Sie bei der Protokollierung beachten. Zum einen sollte ihre Eventlog eine ausreichend Größe haben, damit Sie Einträge auch wirklich lesen können und sie sollten wachsam sein, wenn der Event 517 erscheint. Dieser besagt, dass jemand das Eventlog gelöscht hat.
Die Größe des Eventlogs sollten Sie auch am besten über eine Gruppenrichtlinie konfigurieren, damit alle Server einheitlich eingestellt sind.
Welche Events sind wichtig ?
Die Frage ist gar nicht so einfach zu beantworten, da Windows je nach Version mehrere Events generiert und es den klassischen "ich melde mich an "-Event so nicht gibt. Es ist schon ein Unterschied, ob ich mich auf dem DC anmelde oder auf einem Client. Wenn ich auf einem Clients angemeldet bin, dann ist es noch ein Unterschied, ob ich mir vom DC nur ein Kerberos-Ticket für den Zugriff auf einen anderen Server besorge oder per Netzwerk auf eine Freigabe auf dem DC selbst zugreife. Ich habe einige Zeit gesucht und mich auf den Event 540 konzentriert, auch wenn dieser erst seit Windows 2000 verfügbar ist. Wenn Sie also Windows NT4 überwachen wollten, dann wäre Event 528 besser. Ein 540er Event hat etwa folgendes Layout:
Ereignistyp: Erfolgsüberw.
Ereignisquelle: Security
Ereigniskategorie: An-/Abmeldung
Ereigniskennung: 540
Benutzer: MSXFAQ\Administrator
Computer: SRV01
Beschreibung:
Erfolgreiche Netzwerkanmeldung:
Benutzername: Administrator
Domäne: MSXFAQ
Anmeldekennung: (0x0,0x159D6BD)
Anmeldetyp: 3
Anmeldevorgang: Kerberos
Authentifizierungspaket: Kerberos
Arbeitsstationsname:
Anmelde-GUID: {2af799e2-2c94-40cb-fb15-a89f33a4619c}
Aufruferbenutzername: -
Aufruferdomäne: -
Aufruferanmeldekennung: -
Aufruferprozesskennung: -
Übertragene Dienste: -
Quellnetzwerkadresse: 10.1.1.10
Quellport: 0
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie un...
Sie erkennen zum einen eine gewisse Struktur, die aber Sprachabhängig ist, so dass ein Parsen nicht ganz trivial ist. Der 528er Event ist vergleichbar aufgebaut und kann mit dem gleichen Parser behandelt werden
Ereignistyp: Erfolgsüberw.
Ereignisquelle: Security
Ereigniskategorie: An-/Abmeldung
Ereigniskennung: 528
Benutzer: MSXFAQ\Administrator
Computer: SRV01
Beschreibung:
Erfolgreiche Anmeldung:
Benutzername: Administrator
Domäne: MSXFAQ
Anmeldekennung: (0x0,0x162721E)
Anmeldetyp: 2
Anmeldevorgang: User32
Authentifizierungspaket: Negotiate
Name der Arbeitsstation: SRV01
Anmelde-GUID: {5f871070-97d1-ca03-2298-5e0c730d9f3a}
Aufruferbenutzername: SRV01$
Aufruferdomäne: MSXFAQ
Aufruferanmeldekennung: (0x0,0x3E7)
Aufruferprozesskennung: 3792
Übertragene Dienste: -
Quellnetzwerkadresse: 127.0.0.1
Quellport: 0
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie un...
Da die Texte aber je nach Sprache unterschiedlich sein können, kann man eigentlich nur auf die Form gehen, d.h. basiert der Parser auf der Position und der Trennung durch das ":"-Zeichen. Interessant sind aber auch noch die fehlgeschlagenen Anmeldeversuche:
Ereignistyp: Fehlerüberw. Ereignisquelle: Security Ereigniskategorie: An-/Abmeldung Ereigniskennung: 529 Benutzer: NT-AUTORITÄT\SYSTEM Computer: SRV01 Beschreibung: Fehlgeschlagene Anmeldung: Grund: Unbekannter Benutzername oder falsches Kennwort Benutzername: fcarius Domäne: NETATWORK Anmeldetyp: 3 Anmeldevorgang: NtLmSsp Authentifizierungspaket: NTLM Name der Arbeitsstation: FC-MOBIL Aufruferbenutzername: - Aufruferdomäne: - Aufruferanmeldekennung: - Aufruferprozesskennung: - Übertragene Dienste: - Quellnetzwerkadresse: 10.1.1.254 Quellport: 0 Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie un...
Besonders interessant können auch Kontoaussperrungen sein. Der Event 539 erscheint, wenn sich ein Benutzer versucht an einem gesperrten Konto anzumelden. Das wäre für einen Helpdesk oder einen SMS-Versand an den Anwender schon interessant. Viel nützlicher ist aber den eigentlichen Sperr-Event" mit der Nummer 644 zu ermitteln und darauf zu reagieren
Ereignistyp: Erfolgsüberw. Ereignisquelle: Security Ereigniskategorie: Kontenverwaltung Ereigniskennung: 644 Benutzer: NT-AUTORITÄT\SYSTEM Computer: DC1 Beschreibung: Gesperrtes Benutzerkonto: Zielkontoname: USER Zieldomäne: Clientname Aufrufercomputername: DOMAIN\USER Aufruferbenutzername: DC1$ Aufruferdomäne: DOMAIN Aufruferanmeldekennung: (0x0,0x3E7) Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Diese Event zeigt nämlich auch den Client, von dem die Anmeldung versucht wurde und letztlich zur Sperrung führte. Das ist ein sehr nützlicher Event um im Helpdesk "Proaktiv" zu arbeiten aber noch mehr um Einbruchversuche zu ermitteln.
Es gibt jede Menge weitere Events, die alle ähnlich aber doch nicht gleich aussehen und daher im Skript individuell zu behandeln sind.
| Event-Typ | Event ID | Bedeutung | Parser |
|---|---|---|---|
| Erfolgsüberwachung | 528 | Erfolgreiche Anmeldung | |
| Fehlerüberwachung | 529 | Fehlerhafte Anmeldung, Falscher User oder Kennwort | |
| 530 | Außerhalb der erlaubten Anmeldezeiten | ||
| 531 | Konto deaktiviert oder ausgesperrt | ||
| 532 | Konto ist abgelaufen | ||
| 533 | Konto darf sich nicht an dem PC anmelden (Beschränkung am AD-Konto Users hinterlegt ) | ||
| 534 | Falsche Anmeldetyp, z.B.: wenn ein Benutzer sich nicht über das Netzwerk anmelden darf und versucht ein Laufwerk oder die Registrierung über LAN zu verbinden oder "Anmelden als Service" oder "Anmelden als Batch" | ||
| 535 | Kennwort ist abgelaufen | ||
| 537 | Unbekannte Anmeldefehler. Mehr sollte im Text stehen | ||
| 539 | Konto ausgesperrt | ||
| Erfolgsüberwachung | 540 | Erfolgreiche Anmeldung | |
| 644 | Konto wurde gesperrt (Zu viele Fehlversuche) | ||
| 681 | Ungültiges Kennwort |
Folgende Artikel enthalten weitere Informationen.
- 174073 Auditing User Authentication
- 182918 Account Lockout Event also Stored in Security Event Log on Domain Controller
- Account Lockout and Management Tools
http://www.microsoft.com/downloads/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en
Enthält das Tool LockoutStatus.exe, welche aus allen DCs den 644-Eintrag einsammelt und als CSV-Datei für weitere Aktionen ausgibt.
Noch ein Wort zum Anmeldetyp, welcher in jedem Event enthalten ist.
- 2 Interaktive Anmeldung
- 3 Netzwerk
- 4 Batch
- 5 Service
- 7 PC entsperren
- 8 Netzwerk mit unsicherem Klartextkennwort
- 9 impersonated logons
Skript
Das Skript ist relativ einfach gestrickt und verbindet sich mittels WMI auf den lokalen Server und liest das Security Eventlog aus. Per Default liest es das bestehende Eventlog aus, schreibt die Daten in eine CSV-Datei und beendet sich dann wieder. Alternativ kann man im Skript über Konstanten einen Monitorbetrieb aktivieren, damit das Skript aktiv auf neue Events wartet. Das macht Sinn, wenn Sie im Skript weiteren Code addiert haben um beim Eintreffen eines bestimmten Events (z.B. Anmeldung eines Dienstkontos) eine Mail bekommen oder andere Aktionen ausgelöst werden sollen.
trackloginevents.1.1.vbs
Nach dem Download als VBS-Datei umbenennen und auf dem Server ablegen
Aufruf:
CSCRIPT trackloginevents.1.1.vbs
Das Skript schreibt ein Log-File für die Fehlersuche, welches Sie später natürlich reduzieren oder ganz deaktivieren sollten. Die Events selbst landen in einer CSV-Datei, die Sie einfach mit Excel oder anderen Programmen verwenden können.
Denkbar ist auch die direkte Weitergabe an z.B. einen SQL-Server. Das Skript liegt ja im Source Code vor.
Weitere Links
- DumpServiceAccounts
- Überwachung von Exchange - Eventlog
- 174073 Auditing User Authentication
- 182918 Account Lockout Event also Stored in Security Event Log on Domain Controller
- Tracking Logon and Logoff Activity in Windows 2000
http://technet.microsoft.com/en-us/library/bb742436.aspx - Interactive Logon Tools and Settings
http://technet.microsoft.com/en-us/library/cc787053.aspx - Interpreting the NT Security Log - Use the Security Log to track
user's activities
http://technet.microsoft.com/en-us/library/cc751315.aspx - Deciphering Account Logon Events
http://blogs.msdn.com/ericfitz/archive/2005/08/04/447934.aspx - Audit Account Logon Events
http://technet.microsoft.com/en-us/library/bb742435.aspx - Minimizing Directory Service Audit Event Noise
http://blogs.msdn.com/ericfitz/ - Auditing: The difference between audit account logon event and
audit logon event
http://geekswithblogs.net/woodenshoe/archive/2005/08/30/51642.aspx - Forensic Log Parsing with Microsoft's LogParser
http://www.securityfocus.com/infocus/1712 - http://www.comp.nus.edu.sg/~aho/kb/eventlog/eventlog.txt
- Monitor The Security Eventlog In Real Time...
http://cwashington.netreach.net/depo/view.asp?Index=747 - Account Lockout Examiner ($)
http://www.netwrix.com/account_lockout_examiner.html
Kommerzielle Software zum überwachen von "gesperrten Accounts".
