Florian hatte vor einigen Wochen das Tool eventcreatef vorgestellt.  Es dient dazu, dass komplette Log-Dateien und nicht nur einzelne Log-Nachrichten in die Ereignisanzeige von Windows geschrieben werden können. eventcreatef delegiert die Aufrufe an das Microsoft-Tool eventcreate, dass die übergebenen Daten in kleinere Teile an den jeweiligen Server sendet.

Somit kann man mit Hilfe von eventcreatef einen zentralen Log-Server auf Basis von Windows Server 2003 o.ä. aufsetzen, der alle Log-Dateien sammelt, z.B. die, die während eines nächtlichen Backups auftreten.

Leider gibt es für Linux kein Tool, dass direkt in die Ereignisanzeige von Windows Server 2003 schreiben kann. Für unsere heterogene Umgebung war dies ein ungünstiger Sachverhalt. Ich musste also einen generischen Service schreiben, der per SOAP die Log-Daten entgegen nehmen konnte und dann dementsprechend an eventcreatef weiterdelegiert.

Dabei ist das unten angehängte Script namens eventcreateservice.php (ECS)heraus gekommen: Es stellt über das Zend Framework eine SOAP-Schnittstelle bereit, die die einfache Methode create besitzt. Wird das Script über eventcreateservice.php?wsdl aufgerufen, wird die WSDL-Datei ausgegeben, über eventcreateservice.php?bash lässt sich ein Bash-Script downloaden, dass mit Hilfe von curl eine Verbindung mit dem SOAP-Service herstellt. An dem Bash-Script muss nichts weiter angepasst werden, da die URLs automatisch generiert werden. Somit lassen sich nativ auf Linux-Maschinen Einträge in die (native) Ereignisanzeige von Windows-basierten Maschinen schreiben.
Ein Syslog-Server ist also nicht mehr nötig. Das Konzept ist besonders für kleinere Unternehmen interessant, die mehr Windows-Maschinen als Linux-Maschinen besitzen und für die ein zentraler Syslog-Server oversized ist.

Nachdem ich ECS fertig entwickelt hatte, ging es nun darum, dass ich die von mir erstellten Log-Einträge nicht in den Standard-Log-Dateien Applikation, System und Sicherheit schreiben wollte, sondern in eine Extra-Logdatei namens Backups.
Florian stellt in der oben bereits genannten URL ein kleines Tool namens CreateEventLog2 bereit. Über die Aufmachung und Fehlerbehandlung der GUI lässt sich streiten, mir ging es um den Funktionsumfang: CreateEventLog2 erzeugt eine neue Log-Datei, die dann in der Ereignsanzeige der MMC angezeigt werden kann.
Damit hatte ich schon ein Großteil erreicht: Ich konnte nun von Windows-Systemen aus Log-Nachrichten auf unserem Log-Server speichern, die Linux-Systeme konnten über das Bash-Script und den SOAP-Service ebenfalls in die Windows-Ereignisanzeige schreiben und schließlich hatte ich ein weiteres Log neben den Standard-Windows-Logs.

Im letzten Schritt ging es nun darum, das von mir definierte Log einem dedizierten Benutzer zugänglich zu machen. Ich wollte in der Konfigurationsdatei von ECS (logischerschweise) keinen Domänen-Administratoraccount eintragen, sondern einen Benutzer mit beschränkten Rechten. Für dieses Vorhaben muss man zuerst einmal ein paar Sachen wissen: Der Zugriff auf die Log-Dateien eines Systems werden über Registry-Einträge geregelt. Es gibt unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog zu jeder Log-Datei einen Schlüssel, der wiederum diverse Attribute enthält. Wichtig ist das Attribut CustomSD: dieses beschreibt anhand eines SDDLs, ob und wer auf dieses Objekt zugreifen darf. Standardmäßig steht in der CustomSD (in meinem Fall zu finden unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Backups\CustomSD) ein String der folgenden Art: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0×7;;;BA)(A;;0×7;;;SO)(A;;0×3;;;IU)(A;;0×3;;;SU)(A;;0×3;;;S-1-5-3). Sieht kryptisch aus, ist es aber eigentlich nicht – wenn man weiß, wie die SDDLs aufgebaut sind.
Kurz dazu: Jeder eingeklammerte Eintrag, z.B. (D;;0xf0007;;;AN) definiert eine Zugriffsregel (ACE). Die erste Regel, die vom System gefunden wird und zutrifft, wird benutzt.

Wie dem auch sei: Es gibt glücklicherweise ein Tool namens sddlparse, das die zugegebenermaßen etwas kryptisch anmutende Zeichenkette analysiert und dann wieder in lesbarer Form ausspuckt.
Nachdem ich damit die benötigten Rechte für einen schreibenden Zugriff auf die Ereignisanzeige auslesen konnte (ADS_RIGHT_DELETE, ADS_RIGHT_READ_CONTROL, ADS_RIGHT_WRITE_DAC, ADS_RIGHT_WRITE_OWNER, ADS_RIGHT_DS_CREATE_CHILD, ADS_RIGHT_DS_DELETE_CHILD und ADS_RIGHT_ACTRL_DS_LIST), erstellte ich einen neuen ACE mit eben diesen Rechten. Die ACE muss an erster Stelle eingefügt werden, so dass der Registry Key wie folgt aussieht: O:BAG:SYD:(A;;LCDCCCWOWDSDRC;;;S-1-5-21-xxx-xxx-xxx-xxx)(nächste ACE…). Der Registry Key wird übrigens bei jedem Aufruf der Ereignisanzeige ausgelesen, somit tritt die Änderung sofort in Kraft.
Ich fügte die SID unseres dedizierten Ereignisanzeigen-Benutzer mit Hilfe der obigen ACE hinzu und war in der Lage mit diesem in die Ereignisanzeige zu schreiben.

Während ich mich in SDDLs und ACEs einarbeitete, fiel auch ein kleineres Tool namens ACECreator ab. Es verbindet sich mit dem Active Directory und sucht mit Hilfe von Ambigious Name Resolution (ANR) Objekte heraus. Diesen Objekten lassen sich dann die Einstellungen verpassen, die man braucht, das passende ACE wird automatisch erzeugt.

Alles in allem war dieses Projekt äußerst spannend. Zwar klingt die Durchführung relativ einfach, allerdings gab einige Probleme mit den Rechten bzw. Benutzeraccount, unter dem eventcreatef lief u.s.w.
Lesenswert sind folgende Links, die ich u.a. für den ACECreator als Referenz herangezogen habe:

• Security Descriptor String Format in der MSDN
• ACEs in der MSDN
• Parsing SDDL Strings bei Jorge
• Overview of Active Directory security
• Vordefinierte Sicherheitskennungen im Technet

Angehängte Downloads

  eventcreateservice-1.0.zip (3.6 KiB, 48 hits)

  ACEGenerator-1.0 (12.2 KiB, 43 hits)