TrackLoginEvents

VBScript und 64Bit !
Viele 32bit COM-Objekte lassen sich auf einem 64bit System nur instanziieren, wenn die 32bit Version von CSCRIPT/WSCRIPT genutzt wird, welcher unter C:\Windows\SysWOW64\cscript.exe liegt.

Dieses Skript deckt noch nicht die Windows 2012 Events ab.

Account Lockout and Management Tools
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465
Diese Werkzeugkiste von Microsoft könnte interessant sein.
Account Lockout Status (LockoutStatus.exe)
http://www.microsoft.com/download/en/details.aspx?id=15201

Was machen meine Anwender ist nur eine Frage in einem Netzwerk. Viel dringender 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 "Fileserver-Funktion" (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.

SecEvent gelöscht

Die Größe des Eventlogs sollten Sie auch am besten über eine Gruppenrichtlinie konfigurieren, damit alle Server einheitlich eingestellt sind.

Relevante Windows 2003 Events

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

Leider scheinen unterschiedliche Windows Versionen unterschiedliche Events zu verwenden. Die Liste ist nicht vollständig

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 ist noch ausgesperrt, daher keine Anmeldung

 

Erfolgsüberwachung

540

Erfolgreiche Anmeldung

 

 

644

Konto wurde gesperrt (Zu viele Fehlversuche)

 

 

675

Versuch sich an einem bereits gesperrten Konto anzumelden

 

 

681

ungültiges Kennwort

 

Erfolgsüberwachung

4740

Win2008: Account wurde gesperrt

 

Folgende Artikel enthalten weitere Informationen.

Speziell aus Aussperren von Konten muss nicht allein über die Eventlogs aller DCs erfolgen, sondern kann auch über Änderungen im Active Directory nachverfolgt werden.

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

Relevante Windows 2008 Events

Dieses Skript deckt noch nicht die Windows 2008 Events ab

Seit Windows gibt es neue Events, die auszuwerten sind.

Event-Typ Event ID Bedeutung Parser

Erfolgsüberwachung

4624

An account was successfully logged on

 

 

4625

An account failed to login.

 

 

4634

An account was logged off

 

 

4740

A User account was locked out

 

 

4767

A User account was unlocked

 

 

4768

A Kerberos authentication ticket (TGT) was requested

 

 

4769

A Kerberos service ticket was requested.

 

 

4776

The domain controller attempted to validate the credentials für an account.

 

 

4672

Special privileges assigned to new logon

 

Relevant sind hier die 4624 und 4625 um Anmeldevorgänge überhaupt zu überwachen. Als Alarmierung kann noch der Event 4740 sein, der eine Kontosperrung kennzeichnet.

  • 947226 Description of security events in Windows Vista and in Windows Server 2008

Hier einige Musterevents:

EventID 4624 -Erfolgreiche Anmeldung

Diese Events sollten die Mehrzahl der Anmeldungen darstellen, wenn Sie nicht gerade einen Angriff abzuwehren haben.

Ereignistyp:          Erfolgsüberw.
Ereignisquelle:       Microsoft-Windows-Security-Auditing
Ereigniskategorie:    (12544)
Ereigniskennung:      4624
Datum:                30.11.2010
Zeit:                 10:41:56
Benutzer:             Nicht zutreffend
Computer:             srv01.msxfaq.de
Beschreibung:
An account was successfully logged on.
 
Subject:
                Security ID:                 S-1-0-0
                Account Name:                -
                Account Domain:              -
                Logon ID:                    0x0
 
Logon Type:                                  3
 
New Logon:
                Security ID:                 S-1-5-21-330543478-484051587-682003330-1005
                Account Name:                fcarius
                Account Domain:              MSXFAQ
                Logon ID:                    0x97140f6
                Logon GUID:                  {004FFC01-84AA-6608-6312-6501C0BD37D8}
 
Process Information:
                Process ID:                   0x0
                Process Name:                 -
 
Network Information:
                Workstation Name:       
                Source Network Address:        -
                Source Port:                   -
 
Detailed Authentication Information:
                Logon Process:                 Kerberos
                Authentication Package:        Kerberos
                Transited Services:            -
                Package Name (NTLM only):      -
                Key Length:                    0

nachfolgende noch eine Erklärung der Felder

EventID 4634 - erfolgreiche Abmeldung

Auch diese Events gibt es wenngleich sie seltener sind. Eine Anmeldung ist immer erforderlich aber wenn ein PC aus dem WLAN-Bereich verschwindet, in den Schalfmode geht o.ä. kann er sich nicht mehr abmelden.

Ereignistyp:        Erfolgsüberw.
Ereignisquelle:     Microsoft-Windows-Security-Auditing
Ereigniskategorie:  (12545)
Ereigniskennung:    4634
Datum:              30.11.2010
Zeit:               11:23:29
Benutzer:           Nicht zutreffend
Computer:           srv01.msxfaq.de
Beschreibung:       
An account was logged off.
 
Subject:
                Security ID:                        S-1-5-21-330543478-484051587-682003330-1005
                Account Name:                       fcarius
                Account Domain:                     msxfaq.de
                Logon ID:                           0x9aa8517
 
Logon Type:                                      3

Event 4740 - Konto locked out

Die "Konto gesperrt"-Meldungen landen alle auf dem PDC-Emulator einer Domäne.

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          15.03.2018 18:27:09
Event ID:      4740
Task Category: User Account Management
Level:         Information
Keywords:      Audit Success User:          N/A
Computer:      DC01.msxfaq.de
Description:
A User account was locked out.

Subject:
	Security ID:		SYSTEM
	Account Name:		DC01$
	Account Domain:		MSXFAQ
	Logon ID:		0x3e7

Account That Was Locked Out:
	Security ID:		MSXFAQ\test
	Account Name:		test

Additional Information:
	Caller Computer Name:

Leider enthalten diese Logs nicht immer die Information, auf welchem Client der Anmeldeversuch stattgefunden hat. Dazu müssen Sie wohl oder übel die Logs der Clients durchsuchen.

Aber schon die Lockout-Meldungen können natürlich erfasst und damit auch "gezählt" werden.

# Einsammlen der "Account Lockout Meldungen

$pdc=(Get-ADDomain).pdcemulator
Get-Winevent `
   -FilterHashTable @{LogName = "Security"; ID = 4740; Providername="Microsoft-Windows-Security-Auditing"} `
   -ComputerName $pdc `
| %{$array = ([xml]$_.ToXml()).event.eventdata.data
   $result = $_ | select (($array.name)+"timecreated"+"message"+"ProviderName"+"id")
   foreach ($item in $array){
      try{$result.([string]$item.name) = [string]$item.'#text'}
      catch{}
   }
   $result
}

Event 4625 - An account failed to log on

Mit diesen Meldungen protokolliert Windows eine fehlerhafte Anmeldung:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          15.03.2018 07:12:56
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure User:          N/A
Computer:      DC01.msxfaq.de
Description:
An account failed to log on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		Administrator
	Account Domain:		PC1

Failure Information:
	Failure Reason:		Unknown User name or bad password.
	Status:			0xc000006d
	Sub Status:		0xc000006a

Process Information:
	Caller Process ID:	0x0
	Caller Process Name:	-

Network Information:
	Workstation Name:	PC1
	Source Network Address:	192.168.178.228
	Source Port:		56986

Detailed Authentication Information:
	Logon Process:		NtLmSsp 
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. 
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. 
The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. 
Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Leider werden diese Meldungen nicht zum PDC-Emulator gesendet sondern auf dem System geloggt, auf dem die Anmeldung fehlgeschlagen ist. Sie kommen also nicht umhin auf den Systemen selbst nachzuschauen.

get-winevent `
   -FilterHashTable @{LogName = "Security"; ID = 4625; Providername="Microsoft-Windows-Security-Auditing"} `
| %{$array = ([xml]$_.ToXml()).event.eventdata.data
   $result = $_ | select (($array.name)+"timecreated"+"message"+"ProviderName"+"id")
   foreach ($item in $array){
      try{$result.([string]$item.name) = [string]$item.'#text'}
      catch{}
   }
   $result
}

Ein gehäuftes Auftreten dieser Meldungen kann als Zeichen für Rate-Versuche gelten.

Event 4776 - The computer attempted to validate the credentials for an account

Besonders angetan hat es mir der Event 4776, da er sehr ausführlich viele Anmeldungen zusammenfasst und im Datenbereich ein Error-Code hinterlegt ist:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10.08.2016 17:59:35
Event ID:      4776
Task Category: Credential Validation
Level:         Information
Keywords:      Audit Success User:          N/A
Computer:      DC01.UCLABOR.DE
Description:
The computer attempted to validate the credentials for an account.

Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:	administrator
Source Workstation:	Hyper-V014
Error Code:	0x0
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4776</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14336</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2017-08-10T15:59:35.481902400Z" />
    <EventRecordID>27321544</EventRecordID>
    <Correlation />
    <Execution ProcessID="504" ThreadID="636" />
    <Channel>Security</Channel>
    <Computer>DC01.UCLABOR.DE</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data>
    <Data Name="TargetUserName">administrator</Data>
    <Data Name="Workstation">Hyper-V014</Data>
    <Data Name="Status">0x0</Data>
  </EventData>
</Event>

Der Error-Code hat folgende Bedeutung:

Hex Code Bedeutung

0xC000006A

An invalid attempt to login has been made by the following user.

0xC0000064

User name does not exist

0xC000006A

User name is correct but the password is wrong

0xC0000234

User is currently locked out

0xC0000072

account is currently disabled

0xC000006F

User tried to logon outside his day of week or time of day restrictions

0xC0000070

workstation restriction

0xC0000193

account expiration

0xC0000071

expired password

0xC0000224

User is required to change password at next logon

0xC0000225

evidently a bug in Windows and not a risk

0xC0000234

The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested

 

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.

TrackLoginvents CSV-Datei

Denkbar ist auch die direkte Weitergabe an z.B. einen SQL-Server. Das Skript liegt ja im Source Code vor.

Trigger

Schon seit Windows 2003 gibt es das Programm "EventTriggers", mit welchem auf bestimmte Events entsprechende Aktionen ausgelöst werden können. Seit Windows 2008 kann dies direkt über den Taskmanager durchgeführt werden.

Sobald also nun ein 644-Event im Security-Eventlog dieses Servers erscheint, kann eine Aktion ("Programm starten", "E-Mail senden", "Messagebox anzeigen") ausgelöst werden. Leider konnte ich nicht ermitteln, ob der Taskmanager den auslösenden Event an das gestartet Programm weiter gibt. Es bleibt also die Programm überlassen, nach dem Start im Eventlog nach seinem Auslöser zu suchen. Zudem müsste so eine Logik natürlich auf jedem DC installiert werden.

PowerShell Version?

Ich plane die nächste Version als PowerShell Skript zu schreiben. Bis dahin hier schon ein paar Links

Kommerzielle Tools

Das Feld des "Einsammelns von Security und Audit-Events" wird natürlich von verschiedenen Herstellern beackert. Teilweise komplett kommerziell, teilweise als "Lite-Version" sogar kostenfrei oder für kleines Geld. Die Links hier können keinen Marktüberblick geben.

Weitere Links