A 1: Jedesmal, wenn etwas gedruckt wird, erfolgt ein Eintrag im System-Protokoll. Das führt dazu, dass das System-Protokoll auf meinem Druck-Server sehr schnell voll ist. Gibt es eine Möglichkeit, das Protokollieren von Drucker-Ereignissen abzustellen?

Fügen Sie den folgenden Eintrag zum Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers hinzu:

Name: EventLog
Typ: DWORD
Wert: 0

Sie müssen den Rechner nicht neu starten, damit die Änderungen wirksam werden, es genügt, den Spooler-Dienst in Systemsteuerung - Dienste zu beenden und neu zu starten.

A 2: Wie groß wird eine Protokolldatei wachsen, nachdem ich Ihre Maximalgröße geändert habe? Das Protokoll ist im Modus "Ereignisse nie überschreiben". Die Maximalgröße war 256 KB. Ich änderte sie auf 1024 KB. Später dachte ich mir, daß 512 KB genug sind und änderte die Maximalgröße nochmals entsprechend. Die gegenwärtige Größe ist nur 128 KB.

Es kommt darauf an ;-)
Wenn Sie den Rechner zwischendurch nicht neu starten, wird das Protokoll bis auf 1024 KB wachsen. Wenn Sie ihn neu starten, bevor das Protokoll die 512 KB erreicht, wird es nur auf 512 KB wachsen. Wenn Sie den Rechner erst neu starten, nachdem das Protokoll schon größer als 512 KB ist, wird lediglich der freie Platz aufgefüllt, aber es wird nicht weiter wachsen. (Die Protokolldatei wächst immer in Schritten von 64 KB. Nachdem so ein Abschnitt gefüllt ist, wird der nächste 64 KB-Abschnitt für die Protokolldatei reserviert.) Das Neustarten des Rechners hat übrigens den gleichen Effekt wie das Löschen aller Ereignisse.
Die Patentlösung lautet in jedem Fall: Um vorhersagbare Ergebnisse zu erhalten, empfiehlt es sich, alle Ereignisse zu löschen, nachdem irgendwelche Protokolleinstellungen geändert wurden!
(Wenn Sie Elwiz für die Änderungen der Einstellungen verwenden, können Sie das Protokoll dabei automatisch sichern und löschen lassen.) Ja. Wenn das Protokoll im "Überschreib-Modus" und voll ist (so daß das Überschreiben tatsächlich statt findet), können Sie die erlaubte Maximalgröße zwar auch erhöhen, aber die Protokolldatei wird solange nicht wachsen, bis sie gelöscht wurde.
Die Patentlösung lautet in jedem Fall: Um vorhersagbare Ergebnisse zu erhalten, empfiehlt es sich, alle Ereignisse zu löschen, nachdem irgendwelche Protokolleinstellungen geändert wurden!

A 3: Ich habe einen Rechner, auf dem die Maximalgröße aller Protokolldateien auf 512 KB eingestellt ist. Das Anwendungsprotokoll ist nur 256 KB groß, aber jedesmal, wenn der Rechner neu gestartet wird, sagt NT, es wäre voll. Sowohl Elwiz als auch NTs Ereignisanzeige sagen mir, daß die Maximalgröße 512 KB ist. Sowohl Elwiz als auch der Explorer sagen mir, daß die gegenwärtige Dateigröße 256 KB ist. Wieso also weigert sich der Ereignisprotokollierdienst, weitere Ereignisse aufzunehmen?

Sind Sie sicher, daß niemand die Protokolleinstellungen geändert hat, nachdem das Protokoll das letzte mal gelöscht wurde? Das von Ihnen geschilderte Verhalten ist reproduzierbar:

1. Stellen Sie ein Protokoll auf "Ereignisse überschreiben (falls notwendig)" ein.
2. Setzen Sie die Maximalgröße auf 256 KB.
3. Löschen Sie das Protokoll.
4. Füllen Sie es, bis die ältesten Ereignisse überschrieben werden.
5. Ändern Sie die Einstellung auf "Ereignisse nie überschreiben".
6. Wenn Sie jetzt die Maximalgröße ändern, bewirkt das kein Wachstum der Protokolldatei, solange sie nicht gelöscht wird. Auch ein Neustart hift da nicht.

Die Ereignisanzeige von NT warnt Sie nicht vor diesem unerwarteten Verhalten (wohl aber, wenn Sie die Maximalgröße verringern).
Die Patentlösung lautet in jedem Fall: Um vorhersagbare Ergebnisse zu erhalten, empfiehlt es sich, alle Ereignisse zu löschen, nachdem irgendwelche Protokolleinstellungen geändert wurden!

A 4: Ein KB-Artikel besagt, dass, wenn der Registrierungswert CrashOnAuditFail auf 1 gesetzt ist, NT absichtlich abstürzen wird, wenn das Sicherheitsprotokoll voll wird. Danach können nur noch Administratoren auf den Rechner zugreifen. Beeinflußt CrashOnAuditFail auch das Verhalten des Rechners, wenn System- oder Anwendungsprotokoll voll werden?

Nein, CrashOnAuditFail hat nur Einfluß auf das Verhalten bei vollem Sicherheitsprotokoll, das sich nicht im Überschreibmodus befindet.

A 5: Beim Überprüfen eines Sicherheitsprotokolls stellte ich etwas Merkwürdiges fest: Das Ende eines Prozesses war zwar nach dessen Beginn protokolliert, aber die angegebene Zeit lag davor. Wie ist so etwas möglich?

Wahrscheinlich hat jemand die Systemzeit geändert. Ich habe keine Ahnung, warum diese Möglichkeit so lange fehlte. Aber seit Wondows XP gibt es nun endlich ein Sicherheitsereignis 520, welches Änderungen an der Systemzeit protokolliert.

A 6: Woher kommt das Sicherheitsereignis 642 mit dem Benutzernamen "Anonymous-Anmeldung"?

NT verwendet das Konto "Anonymous-Anmeldung" für einige Aktivitäten, die das System selbst erledigt, beispielsweise zum Ändern des Kennworts des Rechnerkontos in einer Domäne. Wenn beispielsweise Zielkontenname SERVER2$ lautet, hat der PDC wahrscheinlich das Kennwort für das Rechnerkonto von SERVER2 geändert. Standardmäßig werden die Kennwörter aller Domänenmitglieder aller 7 Tage geändert, wobei ein solches Ereignis erzeugt wird.
Aber auch das Ändern der Kennwörter von Benutzerkonten kann unter einem Prozess stattfinden, der unter der "Anonymous-Anmeldung" läuft - z.B. wenn ein abgelaufenes Kennwort während der Anmeldung geändert wird. Näheres dazu finden Sie in Antwort 17.

A 7: Ich erhalte eine Menge von Ereignispaaren mit den IDs 528 und 538 (Benutzeran- und -abmeldung). Zuerst kommt Ereignis 528 (Anmeldung), und bald danach folgt Ereignis 538 (Abmeldung). Ich weiß, daß der Benutzer sich nicht abmeldet...

Prüfen Sie den Anmeldetyp der Ereignisse.

• Wenn er 3 (Netzwerkanmeldung) ist, so handelt es sich um Netzwerkanmeldungen. Solche Ereignisse finden zum Beispiel statt, wenn sich Benutzer mit freigegebenen Ressourcen eines Rechners verbinden. Auf jedem Server gibt es eine Einstellung für die maximale Dauer einer inaktiven Benutzersitzung in Minuten, bevor die Verbindung automatisch getrennt wird. Der Vorgabewert ist 15 Minuten. Somit können Sie mehrere solcher Ereignispaare erhalten, wenn ein Benutzer stundenlang mit einer Netzwerkressource verbunden ist und diese nur selten nutzt. Der Server wird dann nach der angegebenen Sitzungsruhezeit die Verbuindung automatisch beenden und der Client wird die Verbindung neu aufbauen, wenn der Benutzer wieder auf die Ressource zugreifen will. Der Benutzer bekommt diese An- und Abmeldungen überhaupt nicht mit.
• Der Anmeldetyp 4 (Batch-Anmeldung) wird unter NT 4 nur protokolliert, wenn Sie den neuen Scheduler-Dienst installiert haben, der mit IE 5 geliefert wurde. Dieser neue Scheduler-Dienst protokolliert die An- und Abmeldungen der geplanten und ausgeführten Aufgaben, weil jeder Task unter einem anderen Konto laufen kann. Der ursprünglich mit NT 4 geleiferte Schedule-Dienst starte alle Aufgaben mit dem Konto, mit dem er selbst läuft, so daß dort beim Start eines Jobs keine Anmeldung protokolliert wird, weil es keine gibt (der Dienst läuft ja schon).

Am einfachsten mit dem Befehl
NET CONFIG SERVER /AUTODISCONNECT:Minuten
Mir sind Berichte bekannt, wonach der Systemmonitor perfmon.exe in einem fort An- und Abmeldungen erzeugt haben soll, während damit ein Netzwerkrechner überwacht wurde. Ich selbst konnte dieses Verhalten bisher nicht reproduzieren.

A 8: Gibt es bekannte Bugs in der Sicherheits-Ereignisprotokollierung von NT?

Die Ereignisprotokollierung von NT 4.0 hat mehr Schwachstellen, als Ihnen lieb sein dürfte. Einige Beispiele:

• Sicherheitsereignis 513 ist erst ab NT-Version 5 implementiert.
• Viele Ereignisse sollten theoretisch nur paarweise auftreten. Beispielsweise sollte jedes gestartete Programm auch irgendwann beendet werden. Aber selbst wenn ein Rechner monatelang ohne Neustart durchläuft, werden Ihnen folgende Ungereimtheiten auffallen:
  • Es werde weniger Sicherheitsereignisse 538 als 528 protokolliert (es müßten theoretisch gleich viele sein).
  • Anmeldefehlversuche des Bildschirmschoners (Anmeldung Typ 7) werden fälschlicherweise als Typ 2 gemeldet.
  • Es wird nur ein Ereignis 528 protokolliert, wenn der Bildschirmschoner beendet wird, aber kein Ereignis, wenn er gestartet wird.
  • Es werde weniger Sicherheitsereignisse 562 als 560 protokolliert (es müßten theoretisch gleich viele sein).
  • Es werde weniger Sicherheitsereignisse 593 als 592 protokolliert (es müßten theoretisch gleich viele sein).
• Das Protokollieren des Sicherheitsereignisses 592 ist unzuverlässig (weitere Informationen dazu finden Sie in der Dokumentation von R592.zip)
• Weitere Sicherheitsereignisse sind zwar dokumentiert, aber bis einschließlich NT-Version 4 nicht implementiert (weitere Informationen dazu finden Sie in Microsofts KB-Artikel Q173059)

A 9: Gibt es bekannte Bugs in der Druck-Ereignisprotokollierung von NT?

Das Protokollieren der Druckereignisse ist ziemlich unzuverlässig:

• Windows NT ist nicht in der Lage, bei Druckausgaben von DOS-Programmen zu erkennen, wieviele Seiten gedruckt wurden. Das gleiche gilt für Umleitungen der Ausgabe von Kommandozeilenprogrammen an der Eingabeaufforderung. Unabhängig von der Anzahl der gedruckten Seiten werden in diesen Fällen 0 Seiten gemeldet.
• Es werden viele Druckjobs falsch protokolliert, wenn mehrere Exemplare eines Dokumentes gedruckt werden. Im Eventlog steht dann nur die Seitenzahl für ein Exemplar! Wird also ein 3-seitiges Dokument 10 mal gedruckt, so berichtet das Eventlog lediglich den Druck von 3 Seiten! Das Auftreten dieses Fehlers hängt von der Anwendung ab, aus der gedruckt wird. So meldet "Microsoft Winword 7.0" die falsche Seitenzahl, "Microsoft Write" dagegen die richtige.
• Ein weiteres Problem haben Sie, wenn an Ihrem LAN auch Maschinen hängen, die eine DOS-Version von Windows benutzen, sei es Win 3.11 oder Win9x. Wird von einem solchen Rechner gedruckt, so wird als Anzahl der gedruckten Seiten stets 0 angegeben, die Anzahl der gedruckten Bytes aber richtig ins Eventlog eingetragen.

A 10: Kürzlich stellte ich eine signifikante Verlangsamung auf meinem Windows-Rechner fest und entdeckte, daß das Ereignisprotokoll überlief. Ich löschte es und stellte eine augenblickliche Leistungssteigerung bei mehreren Anwendungen fest. Wieso wurde mein Ereignisprotokoll so groß? (Eingestellt ist "Ereignisse überschreiben, die älter als 7 Tage sind" und trotzdem waren uralte Ereignisse in den Protokollen.)

Ereignisse werden nur überschrieben, wenn das Protokoll voll ist. Ihre Einstellung gibt nur an, daß keine Ereignisse überschrieben werden können, die jünger als 7 Tage sind. Falls also die Maximalgröße Ihres Protokolls so groß gewählt ist, daß sie Monate nach dem letzten Löschen des Protokolls noch immer nicht erreicht ist, werden Sie dort solange alle Ereignisse vorfinden, bis der Speicherplatz der ältesten Ereignisse benötigt wird, um neuere Ereignisse unterzubringen.

A 11: Es sieht so aus, als ob bei manchen erfolgreichen Anmeldugen doppelte Einträge protokolliert würden. Der zweite Eintrag hat entweder genau die gleiche Zeit oder er wird ein oder zwei Sekunden später erzeugt.

Prüfen Sie, um was für Anmeldungen es sich handelt. Ein Ereignis 528 wird vom Typ 2 sein, das ist eine interaktive Anmeldung. Wenn der Benutzer während der Anmeldung mit freigegebenen Verzeichnissen (z.B. seinem Home-Verzeichnis) verbunden wird, so wird auf jedem Rechner, mit dem er sich verbindet, ein Ereignis 528 vom Anmeldetyp 3 (Netzwerkanmeldung) erzeugt. Ein solches Ereignis wird selbst dann erzeugt, wenn die Verbindung zu einem freigegebenen Verzeichnis erfolgt, das sich auf dem lokalen Rechner befindet, was dann bei oberflächlicher Betrachtung wie eine doppelte Anmeldung aussieht.

A 12: Der Rechner und alle Dienste arbeiten normal, aber nur Benutzer, die zur Gruppe der Administratoren gehören, können sich lokal oder über das Netzwerk anmelden. Die Berechtigungen in Benutzer-Manager - Richtlinien - Benutzerrechte erlauben das aber jedem Benutzer.

Das sieht so aus, als hätte es nichts mit der Ereignisprotokollierung zu tun, nicht wahr? Aber der Grund für das seltsame Verhalten ist wahrscheinlich folgender:

• Das Sicherheitsprotokoll war voll.
• Der Registrierungswert CrashOnAuditFail war zuvor auf 1 gestzt, jetzt ist er 2.

Der bequemste Möglichkeit, diesen Wert für alle Rechner Ihres Netzwerks zu setzen und zu überprüfen, bietet natürlich Elwiz ;-).

A 13: Welche Möglichkeiten gibt es, Domänen-Benutzer davon abzuhalten, die anderen Ereignisprotokolle (System, Anwendung) der Server zu durchstöbern?

• Sie können den Benutzern das Recht Ausführen für das Programm eventvwr.exe entziehen. Aber wenn Sie ihnen ermöglichen wollen, die lokalen Protokolle anzusehen, haben Sie ein Problem, weil eventvwr.exe dann auch alle Protokolle außer dem Sicherheitsprotokoll auf dem Server für die Benutzer öffnet.
• Sie können einen Registrierungswert für jedes Protokoll setzen:
  Pfad: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\System
   und: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\Application
  Typ: REG_DWORD
  Name: RestrictGuestAccess
  Das Setzen dieses Wertes auf 1 verhindert den freien Zugriff auf das jeweilige Protokoll.
• Sie könnten Elwiz installieren ;-) Das Programm sieht im Gegensatz zu NTs Ereignisanzeige auf die Berechtigungen der Protokolldateien und öffnet nur solche Protokolle, für die der Benutzer das Recht Lesen hat.

A 14: Gibt es eine Möglichkeit, z.B. alle fehlgeschlagenen Anmeldeversuche einer Domäne in einer einzigen Ereignisprotokolldatei zu vereinigen, oder muß ich dazu die Protokolle aller Arbeitsstationen durchsuchen?

• Die Auswerteprogramme aus der Sammlung Report Event für Windows bieten alle die Möglichkeit, die Protokolle sämtlicher Rechner, die in einem Verzeichnis gespeichert sind, mit einem Aufruf auszuwerten. Trotzdem kann es ganz nützlich sein, die betreffenden Ereignisse aus allen Protokollen in einer gemeinsamen Datei zu sammeln. Dazu gibt es das Programm MER als Bestandteil von Report Event für Windows.
• Das Programm Elwiz bietet die Möglichkeit, sich bei wichtigen Ereignissen alarmieren zu lassen. Die Alarmierung funktioniert so, dass die Alarm-Ereignisse in eine separate Datei kopiert und dann von Elwiz angezeigt werden. Außerdem haben Sie die Möglichkeit, Filterregeln zu definieren, die mehrere Ereignisse zusammenfassen. So könnte eine Regel zum Beispiel alle Ereignisse 529, die innerhalb einer Minute in Ihrem Netzwerk auftraten, in einem Datensatz zusammenfassen.

A 15: Wie kann ich das Erzeugen von Einträgen in allen Ereignisprotokollen ganz abstellen? Ich kümmere mich sowieso nicht um die Protokolle.

Deaktivieren Sie den Ereignisprotokollierdienst. Aber ich rate davon ab!

Wenn Sie beispielsweise zu Hause einen Rechner verwenden, auf den nur Sie selbst Zugriff haben, werden Sie sich wahrscheinlich nicht um das Sicherheitsprotokoll scheren, aber trotzdem kann die Ereignisprotokollierung selbst hier noch sehr nützlich für Sie sein! Beispielsweise protokolliert Windows Fehler, die beim Zugriff auf die Festplatte auftreten und oft die Vorboten einer sterbenden Festplatte sind. Sie kommen also wahrscheinlich besser, wenn Sie zu Hause nur die Überwachung der Sicherheitsereignisse abschalten und den Ereignisprotokollierdienst weiter laufen lassen (und vor allem ab und zu einen Blick auf die Protokolle werfen).

A 16: Manche Zeiten in meinen Ereignisprotokollen werden um eine Stunde verschoben angezeigt

Wahrscheinlich haben Sie bei der Zeitzone auch "Uhr automatisch auf Sommer-/Winterzeit umstellen" aktiviert. Das ist der Grund dafür, dass Ereignisse, die in dem anderen Halbjahr stattfanden, um eine Stunde verschoben angezeigt werden, denn NT protokolliert intern alle Ereignisse in GMT und rechnet die Zeiten nur für die Anzeige um. Dieses Verhalten ist in KB article 129574 dokumentiert. Wenn Sie es nicht mögen, können Sie "Uhr automatisch auf Sommer-/Winterzeit umstellen" deaktivieren.

A 17: Ereignis 627 zeigt, dass NT-AUTORITÄT\ANONYMOUS versucht, das Kennwort eines Benutzers zu ändern. Es wird ein Zielkontenname angezeigt, aber kein Benutzername.

Diese Art von Ereignissen ohne "Benutzername des Aufrufers" wird protokolliert, wenn das Kennwort des Benutzers abgelaufen ist und dieser während der Anmeldung aufgefordert wird, das Kennwort zu ändern. Ereignis 627 kann vom Typ Erfolg oder Fehler sein, je nachdem, ob der Benutzer erfolgreich war oder nicht. Falls Sie wissen möchten, auf welchem Rechner da jemand sein Kennwort ändern möchte, hilft Ihnen das Ereignis 627 auf dem Server nicht weiter. Sie müssen die Sicherheitsprotokolle aller Arbeitsstationen nach einem Ereignis 537 durchsehen, welches kurz vor dem 627 aufgetreten ist und auf den gleichen Benutzer verweist.

A 18: Ich frage mich, wieso es gelegentlich Tage mit "Löchern" (ohne Ereignisse) in meinen Protokollen gibt?

Wie voll sind Ihre Logdateien? Elwiz kann Ihnen sagen, wieviel Prozent der maximal erlaubten Größe der Logdateien belegt sind.
Falls Sie z.B. die Option "Überschreiben nach 7 Tagen" gewählt haben, die Protokolldatei aber schon nach 3 Tagen voll ist, wird die nächsten Tage natürlich kein Ereignis geschrieben.

A 19: Ich werde einer Lizenzverletzung beschuldigt, die ich überhaupt nicht begangen habe! Im Systemprotokoll steht ein Ereignis 26, welches behauptet, ich hätte den Produkttyp verändert!

Haben Sie zufällig die Überwachung für Teile der Registrierung eingeschaltet? Wenn Sie die Überwachung für
HKLM\System\CurrentControlSet\Control\ProductOptions\ProductType und/oder
HKLM\System\Setup\SystemPrefix
aktivieren, bekommen Sie diese dumme Meldung. Scheinbar betrachtet Microsoft das Überwachen dieser Registrierungsschlüssel als Verletzung der Software-Lizenz.

A 20: Gibt es eine Software, die es einer Person erlaubt, einzelne Ereignisse aus dem Ereignisprotokoll zu löschen?

Es kommt darauf an, ob Sie:
(A) das aktive Ereignisprotokoll, welches vom System verwendet wird, oder
(B) Ereignisprotokolldateien, die bereits gespeichert wurden und vom System nicht mehr gesperrt sind
meinen.

(A) - Weil der Ereignisprotokolldienst die Logdateien mit exklusivem Zugriff öffnet, müssen Sie erst diesen Dienst sabotieren, wenn Sie selbst direkt in die Logdateien schreiben wollen. Im September 2000 verbreitete Arne Vidstrom ein Programm WinZapper, welches den Ereignisprotokolldienst dazu brachte, seine Arbeit einzustellen, ohne sich dabei aber zu beenden. Nachdem das vollbracht ist, gibt es keinen Unterschied mehr zu Fall (B). Sie müssen übrigens mit einem Administrator-Konto angemeldet sein, um WinZapper zu benutzen.

(B) - Das ist möglich. Man kopiert einfach das gesamte Protokoll in eine andere Datei und überspringt dabei die Sätze, die man löschen möchte. MER eignet sich dazu, falls Sie z.B. alle Einträge mit einer bestimmten Ereignis-ID entfernen wollen.

A 21: Warum sollte ich das Administrator-Konto umbenennen? Ein Angreifer kann doch trotzdem leicht den Namen des vordefinierten Administrator-Kontos herausfinden.

Wenn Sie das Administrator-Konto umbenennen und dann ein Gastkonto mit dem Namen "Administrator" einrichten, können Sie Glück haben und damit Möchtegern-Hacker in die Falle locken. Wenn Sie dann Anmeldeversuche mit diesem Administrator-Konto in Ihrem Ereignisprotokoll entdecken, wissen Sie sofort, dass da etwas vor sich geht, was eigentlich nicht sein sollte.

A 22: Wie speichere ich Ereignisprotokolldateien als ASCII-Datei ab?

• Wenn Sie das mit einem GUI-Programm machen wollen, empfehle ich Elwiz. Damit können Sie sowohl die zu speichernden Ereignisse als auch darin die Felder filtern, die zu speichern sind.
• Ab NT 5.0 (aka Windows 2000) können Sie auch die Ereignisanzeige verwenden. Das Programm ignoriert allerdings beim Datenexport die eingestellten Filter.
• Wenn Sie die Aufgabe lieber mit einem Kommandozeilenprogramm erledigen wollen, empfehle ich dumpel aus dem Ressource Kit.

A 23: Wie werden interaktive Anmeldungen über das Netzwerk protokolliert?

Das hängt von der Anwendung ab, mit der Sie sich anmelden:

• Manche Programme, wie z. B. rcmd.exe aus Microsofts Ressource Kit, erlauben eine interaktive Anmeldung, die überhaupt nicht protokolliert wird.
• Andere Programme, wie z. B. psExec.exe, protokollieren die Anmeldung als Typ 2 (interaktiv).

A 24: Gibt es eine API-Funktion, um heraus zu finden, zu wieviel Prozent ein Ereignisprotokoll mit Daten gefüllt ist?

Nein, Sie müssen selbst eine Funktion schreiben, um an diese Daten zu gelangen.

A 25: Ich bin Administrator in einem großen NT-Netzwerk mit vielen Benutzern mit Admin-Rechten. Es sollen die Änderungen, die von den Admins an den Benutzerkonten durchgeführt wurden, sowie die Änderungen an den Servern selbst protokolliert werden.

Der Ereignisprotokoll-Dienst erlaubt es Ihnen, die Änderungen an Benutzerkonten, Sicherheitsrichtlinien, und anderen Objekten zu protokollieren.
Wenn es aber eine große Anzahl an Administratoren gibt, sollten Sie nicht zu viel Vertrauen in die Protokolle haben. Jeder Administrator ist in der Lage, die Überwachungsrichtlinien zu ändern. Jemand könnte also die Überwachung abschalten, etwas an einem Benutzerkonto ändern, und dann die Überwachung wieder einschalten. Sie können dann von der Änderung an dem Benutzerkonto in den Protokollen keine Spuren finden.

A 26: Mein Sicherheitsprotokoll füllt sich mit Ereignissen 529 (fehlgeschlagene Anmeldung) für den Benutzer RECHNER$

Das sieht so aus, als wäre das Kennwort von RECHNER nicht mehr mit dem DC synchronisiert. Gewöhnlich hilft es, RECHNER aus der Domäne zu entfernen und dann erneut hinzuzufügen.

A 27: Warum werden keine Ereignisse 592 und 593 protokolliert, wenn eine 16-Bit-Anwendung läuft?

Die Ereignisse 592 und 593 werden nur für 32-Bit-Anwendungen protokolliert.
Wenn Sie die Ausführung von 16-Bit-Anwendungen protokollieren möchten, müssen Sie die Überwachung für Objektzugriffe aktivieren. Danach können Sie in den Sicherheitsereignissen mit der ID 560 nach Ereignissen mit Zugriff: Ausführen suchen.

A 28: Welche Einstellungen sind nötig, um lediglich die Änderung von Datei-Zugriffsrechten zuverlässig zu protokollieren?

Sie müssen Berechtigungen ändern: Erfolgreich und Fehlgeschlagen am sichersten für Jeder überwachen.

Sie müssen aber wissen, dass jemand nun immer noch zuerst diese Überwachung ausschalten und dann die Berechtigungen ändern kann, ohne dass das protokolliert wird. Die einzige Möglichkeit, Änderungen der Überwachungseinstellungen zu protokollieren, scheint die Überwachung von erfolgreichen Schreibzugriffen zu sein. Nur so erhalten Sie ein Ereignis, wenn die Überwachung abgeschaltet wird. Allerdings führt diese Einstellung unweigerlich in kurzer Zeit zu riesigen Protokolldateien.

Der Grund für diesen unbefriedigenden Zustand liegt vielleicht darin, dass die Überwachungseinstellungen ja in die Datei geschrieben werden. Es wäre natürlich trotzdem sehr begrüßenswert, wenn es eine Möglichkeit gäbe, nur sicherheitsrelevante Ereignisse zu protokollieren.

A 29: Gibt es Probleme mit dem Überwachen der Registrierungs-Rootkeys?

Auf wichtigen Rechnern kann es sinnvoll sein, sich über Zugriffsversuche auf das Dateisystem oder die Registrierung ein Bild zu machen. Um über das Netzwerk auf die Registrierung eines Rechners zugreifen zu können, muß man immer zuerst eine Verbindung zu einem der beiden Rootkeys HKEY_LOCAL_MACHINE oder HKEY_USERS aufbauen. Sie können also in den Sicherheitsrichtlinien die Überwachung von Objektzugriffsversuchen aktivieren und in den Eigenschaften der beiden Registrierungsschlüssel einen Überwachungseintrag hinzufügen.

Das Problem dabei: Nachdem der Rechner neu gestartet wurde, hat der die Überwachungseinträge für die beiden Rootkeys verloren. Dieses Problem betrifft alle aktuellen Versionen von Windows.

Workaround: Erzeugen Sie einen RegAudit-Befehl zur Wiederherstellung der Überwachungseinstellungen im Startscript des Rechners.

 

A 30:Welche Ereignisse werden bei der lokalen An- und Abmeldung eines Benutzers protokolliert?

Bei der Anmeldung wird Ereignis 528 protokolliert, wobei der Typ 2 bedeutet, daß es sich um eine interaktive Anmeldung handelt.

Nach dem Ende des Abmeldevorgangs wird Ereignis 538 protokolliert. Nun kann es aber vorkommen, daß der Benutzer zugleich den Rechner herunterfährt. Das bedeutet dann, das auch der Ereignisprotokollierdienst herunter gefahren wird und eventuell schon beendet ist, wenn der Abmeldevorgang des Benutzers abgeschlossen ist. Es kann also vorkommen, daß das Ereignis 538 überhaupt nicht protokolliert wird.

Aus diesem Grunde wurde mit Windows XP und Windows 2003 das Ereignis 551 eingeführt. Dieses Ereignis wird erzeugt, wenn ein Abmeldevorgang eingeleitet wurde. Das Ereignis wird nur für interaktive Benutzersitzungen erzeugt. Bei modernen Windows-Versionen treten die Ereignisse also in folgender Reihenfolge auf:

Anmeldung: 528

Beginn der Abmeldung: 551

Abschluss der Abmeldung: 538 (nur vorhanden, falls Rechner nicht herunter gefahren wurde)

 

A 31: Was bedeutet z.B. die Anmeldekennung (0x0,0x3E5)?

(0x0,0x3E5) wird für Dienste verwendet, die unter dem vordefinierten Benutzerkonto LOKALER DIENST ausgeführt werden.
(0x0,0x3E4) wird für Dienste verwendet, die unter dem vordefinierten Benutzerkonto NETZWERKDIENST ausgeführt werden.
Ande Benutzerkonten verwenden wechselnde Anmeldekennungen. Die Zahlen werden immer größer, je länger der letzte Bootvorgang zurückliegt.

 

A 32: Sind mit dem neuen Ereignisprotokoll von Vista alle Probleme der Vorgängerversionen beseitigt?

Sicher nicht. Es gibt auch unter Vista Ereignisse, deren Aufbau Anlass für Kritik bietet:

• Sicher bekannt sind die Dr. Watson-Ereignisse älterer Windows-Versionen, die den gesamten Text als Binärdaten speichern, mit dem Resultat, dass die mitgelieferte Ereignisanzeige (im Gegensatz zu Elwiz ;-) den Text nicht in einer leicht lesbaren Form wiedergeben kann.
  Auch unter Vista gibt es solche Ereignisse, z.B. im Systemprotokoll das Ereignis 6013 (bzw. 1917) der Quelle Eventlog. Hier wird der eigentlich lesbare Text durch die Speicherung als Binärdaten für Benutzer der mitgelieferten Ereignisanzeige unnötig schwer lesbar gemacht.
• Sinnvollerweise werden in den Ereignissen nur veränderliche Informationen gespeichert, die dann mit einem außerhalb des Ereignisprotokolls gespeicherten Formatierungsstring zu lesbarem Text formatiert werden. Das verhindert ein unnötiges Aufblähen der Ereignisprotokolle mit redundanten Informationen.
  Wenn Sie in Vista z.B. das Sicherheitsprotokoll löschen, wird ein Ereignis 1102 der Quelle Eventlog mit 4 Werten erzeugt: SID, Anmeldename, Anmeldedomäne und Anmelde-ID des Benutzers. Die Ereignisanzeige zeigt diese Parameter dann ordentlich formatiert an.
  Wenn Sie in Vista aber das Systemprotokoll löschen, wird ein Ereignis 104 der Quelle Eventlog mit 4 Werten erzeugt: Anmeldename, Anmeldedomäne, Channel und ggf. der Name der Datei, in die die gelöschten Ereignisse gespeichert wurden. Die Ereignisanzeige verbirgt diese Parameter dann aber aus unbekannten Gründen in der Normalansicht.
• Nicht nachvollziehbar für mich ist auch die Tatsache, dass zwar beim System-, nicht jedoch beim Sicherheitsprotokoll gespeichert wird, in welche Datei die gelöschten Ereignisse gesichert wurden.