Microsoft Windows AD-Daten erfassen

Dieses Dokument enthält die folgenden Informationen:

  • Bereitstellungsarchitektur und -installationsschritte sowie alle erforderlichen Konfigurationen, die Logs generieren, die vom Chronicle-Parser für Microsoft Windows Active Directory-Ereignisse unterstützt werden. Eine Übersicht der Datenaufnahme von Chronicle finden Sie unter Datenaufnahme in Chronicle.
  • Informationen dazu, wie der Parser Felder im ursprünglichen Log Feldern von Chronicle Unified Data Model zuordnet

Die Informationen in diesem Dokument gelten für den Parser mit dem Aufnahmelabel WINDOWS_AD. Das Aufnahmelabel gibt an, welcher Parser die Logdaten im strukturierten UDM-Format normalisiert.

Hinweis

Dieses Diagramm zeigt die empfohlenen grundlegenden Komponenten in einer Bereitstellungsarchitektur, mit denen Microsoft Windows-Ereignisse erfasst und an Chronicle gesendet werden. Vergleichen Sie diese Informationen mit Ihrer Umgebung, um sicherzustellen, dass diese Komponenten installiert sind. Jede Kundenbereitstellung unterscheidet sich von dieser Darstellung und kann komplexer sein. Folgendes ist erforderlich:

  • Alle Systeme in der Bereitstellungsarchitektur werden mit der UTC-Zeitzone konfiguriert.
  • PowerShell-Skripts werden auf jedem Microsoft Windows AD-Server erstellt und konfiguriert, um USER_CONTEXT- und ASSET_CONTEXT-Daten zu erfassen.
  • NXLog ist auf jedem Microsoft Windows AD-Server installiert, um Daten an den zentralen Microsoft Windows- oder Linux-Server zu senden.
  • Chronicle-Weiterleiter ist auf dem zentralen Microsoft Windows- oder Linux-Server installiert, um Logdaten an Chronicle weiterzuleiten.

    Bereitstellungsarchitektur

Unterstützte Geräte und Versionen prüfen

Der Chronicle-Parser unterstützt Logs aus den folgenden Microsoft Windows-Serverversionen. Microsoft Windows Server wird mit den folgenden Versionen veröffentlicht: Foundation, Essentials, Standard und Datacenter. Das Ereignisschema der von jeder Version generierten Logs unterscheidet sich nicht.

  • Microsoft Windows Server 2019
  • Microsoft Windows Server 2016
  • Microsoft Windows Server 2012

Chronicle-Parser unterstützt Logs, die von der NXLog-Community oder Enterprise Edition erfasst wurden.

Unterstützte Logtypen ansehen

Chronicle-Parser parst und normalisiert Daten, die aus dem Nutzerkontext und dem Asset-Kontext abgerufen wurden. Sie unterstützt Logs, die mit englischem Text generiert wurden, und nicht Logs, die in nicht englischsprachigen Sprachen generiert wurden.

Microsoft Windows AD-Server konfigurieren

So konfigurieren Sie Microsoft Windows AD-Server in der Bereitstellungsarchitektur:

  1. Konfigurieren Sie alle Systeme mit der koordinierten Weltzeit UTC.
  2. Erstellen und konfigurieren Sie auf jedem Microsoft Windows Active Directory-Server ein PowerShell-Skript, um Logdaten in einer Ausgabedatei zu erfassen. NXLog liest die Ausgabedatei und sendet Daten an den zentralen Microsoft Windows- oder Linux-Server.
  3. Erstellen Sie das PowerShell-Skript. Sehen Sie sich folgendes Beispiel an. Ändern Sie den Wert von $OUTPUT_FILENAME in den Speicherort, an den die Ausgabedatei geschrieben werden soll. Diese Datei wird von NXLog gelesen. Die Daten müssen im JSON-Format gespeichert werden. Setzen Sie die Codierung auf utf8. Verwende beim Aufrufen der Cmdlets Get-ADUser und Get-ADComputer den Parameter -Filter anstelle des Parameters -LDAPFilter.

    # Set the location where the log file will be written
    $OUTPUT_FILENAME="<Path_of_the_output_file>"
    
    If (Test-Path -Path $OUTPUT_FILENAME) { Remove-Item -path $OUTPUT_FILENAME -ErrorAction SilentlyContinue}
    
    # USER_CONTEXT: Gets all Active Directory users and their properties.
    Get-ADUser -Filter * -properties samAccountName | % { Get-ADUser $_.SamAccountName -properties * | ConvertTo-JSON -compress | Out-File -encoding utf8 $OUTPUT_FILENAME -Append }
    
    # ASSET_CONTEXT: Gets all Active Directory assets and their properties.
    Get-ADComputer -Filter * -properties samAccountName | % { Get-ADComputer $_.SamAccountName -properties * | ConvertTo-JSON -compress | Out-File -encoding utf8 $OUTPUT_FILENAME -Append }
    
  4. Erstellen Sie eine wiederkehrende Aufgabe, mit der das Skript ausgeführt wird, um Daten abzurufen und in die Ausgabedatei zu schreiben.

    1. Öffnen Sie den Taskplaner.
    2. Klicken Sie im rechten Bereich auf „Aufgabe erstellen“.
    3. Geben Sie den Namen und die Beschreibung der Aufgabe ein.
    4. Klicken Sie das Kästchen „Mit höchsten Berechtigungen ausführen“ an, damit alle Daten abgerufen werden. Aufgaben erstellen

    5. Auf dem Tab „Trigger“ können Sie festlegen, wann die Aufgabe wiederholt werden soll.

    6. Fügen Sie auf dem Tab „Aktion“ eine neue Aktion hinzu und geben Sie den Pfad der Datei an, in der das Skript gespeichert ist. Zeitplan erstellen

  5. Installieren Sie den NXLog-Agent auf jedem Microsoft Windows Active Directory-Server. Diese Anwendung leitet Protokolle an den zentralen Microsoft Windows- oder Linux-Server weiter. Folgen Sie der Dokumentation zu NXLog.

  6. Erstellen Sie für jede NXLog-Instanz eine Konfigurationsdatei. Mit dem NXLog-Modul im_file können Sie die Datei lesen und die Zeilen in Felder parsen. Verwenden Sie das om_tcp-Modul, um Daten an den zentralen Microsoft Windows- oder Linux-Server weiterzuleiten.

    Hier ist ein Beispiel für eine NXLog-Konfiguration. Ersetzen Sie die Werte <hostname> und <port> durch Informationen zum Zielserver von Microsoft Windows oder Linux. Fügen Sie im Abschnitt <Input in_adcontext> und der Property File den Pfad der Ausgabe-Logdatei hinzu, die vom PowerShell-Skript geschrieben wurde. Lege immer DirCheckInterval und PollInterval fest. Wenn diese nicht definiert sind, fragt NXLog alle 1 Sekunde nach Dateien ab.

    define ROOT C:\Program Files\nxlog
    define ADCONTEXT_OUTPUT_DESTINATION_ADDRESS <hostname>
    define ADCONTEXT_OUTPUT_DESTINATION_PORT <port>
    
    Moduledir   %ROOT%\modules
    CacheDir    %ROOT%\data
    Pidfile     %ROOT%\data\nxlog.pid
    SpoolDir    %ROOT%\data
    LogFile     %ROOT%\data\nxlog.log
    
    <Input in_adcontext>
        Module im_file
        File "<Path_of_the_output_file>"
        DirCheckInterval 3600
        PollInterval 3600
    </Input>
    
    <Output out_chronicle_adcontext>
        Module  om_tcp
        Host    %ADCONTEXT_OUTPUT_DESTINATION_ADDRESS%
        Port    %ADCONTEXT_OUTPUT_DESTINATION_PORT%
    </Output>
    
    <Route ad_context_to_chronicle>
        Path in_adcontext => out_chronicle_adcontext
    </Route>
    
  7. Starten Sie den NXLog-Dienst in jedem System.

Zentralen Microsoft Windows- oder Linux-Server konfigurieren

Weitere Informationen zum Installieren und Konfigurieren des Forwarders finden Sie unter Installation und Konfiguration des Forwarders unter Linux oder Installieren und konfigurieren des Forwarders unter Microsoft Windows.

  1. Konfigurieren Sie das System mit der UTC-Zeitzone.
  2. Installieren Sie den Chronicle-Forwarder auf dem zentralen Microsoft Windows- oder Linux-Server.
  3. Chronicle-Weiterleitung so konfigurieren, dass Logs an Chronicle gesendet werden. Hier ist ein Beispiel für eine Forwarder-Konfiguration.

      - syslog:
          common:
            enabled: true
            data_type: WINDOWS_AD
            batch_n_seconds: 10
            batch_n_bytes: 1048576
          tcp_address: 0.0.0.0:10518
          connection_timeout_sec: 60
    

Referenz für Feldzuordnung: UPI-Felder für Geräteprotokoll

In diesem Abschnitt wird beschrieben, wie der Parser die ursprünglichen Logfelder den Feldern des einheitlichen Datenmodells zuordnet.

Nutzerkontextprotokolle

NXLog-Feld UDM-Feld
GivenName entity.entity.user.first_name
Nachname Entität.nutzer.last_name
SamAccountName Entität.entity.user.userid
SID.Wert Entität.nutzer.windows_sid
Objektklasse Wenn der Wert „"“ lautet, ist die Entität „
.entity.metadata.entity_type“ auf „USER“ festgelegt.
Objektführung Entität.Nutzer.Produkt_Objekt_ID
Ablaufdatum des Kontos Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Schlechter PwdCount Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Kanonischer Name Entität.enitity.administrative_domain
Ort entity.entity.user.personal_address.city
Unternehmen Entität.nutzer.nutzer.name
Land entity.entity.user.personal_address.country_or_region
Abteilung Entität.entität.nutzer.abteilung
Beschreibung Entität.metadata.description
DisplayName Entität.nutzer.nutzer_anzeigename
EmailAddress entity.entity.user.email_adressen
Mitarbeiter-ID Entität.Nutzer.Nutzer.employee_id
Basisverzeichnis Entität.entity.file.full_path
Startseite Entität.url
HomePhone Entität.Nutzer.Nutzer.Telefonnummern
LetzterBadPasswordPassword Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
letzterLogoff Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Logo: lastLogon Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
LastLogonDate Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Manager Werte für GUID, SAMAccountname und SID sind alle unterschiedlichen UDM-Feldern zugeordnet:
– SID wird in Manager.windows_sid gespeichert
– Distinguished Name (d.h. der Wert im ersten CN) wird in Manager.user_display_name gespeichert
– GUID,SamAccountName in Manager.userid gespeichert
Mitglied Die folgenden Felder im ersten Vorkommen von CN sind festgelegt:
entity.relations.entity.group.group_display_name
entity.relations.entity_type auf GROUP
entity.relations.relationship mit t0-MEMBER
entity.relations.direction auf UNIDIRECTIONAL festgelegt.
Mobiltelefon Entität.Nutzer.Nutzer.Telefonnummern
Büro entity.entity.user.office_address.name
Kennwort abgelaufen Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
PasswordLastSet Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Passwort läuft nicht ab Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Passwort nicht erforderlich Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Primäre Gruppe Folgende Felder sind festgelegt:
- Entität.relations.entity.group.group_display_name
- Entität.relations.entity_type wurde auf GROUP
- Entität.relations.relationship auf MEMBER
direction SET festgelegt.
Dienstprinzipalnamen Wird als „entity.entity.user.attribute.label.key/value“-Paar gespeichert.
Status entity.entity.user.personal_address.state
Adresse entity.entity.user.personal_address.name
Titel Entität.Nutzer.Titel
Datum der Erstellung Entität.Nutzer.Attribut.Creation_time

Logs für Assetkontext

NXLog-Feld UDM-Feld
DNS-Hostname Entität.entity.asset.hostname
SamAccountName Objekt.entity.asset.asset_id
SID.Wert Entität.nutzer.windows_sid
Objektklasse Wenn der Wert „"computer“ ist, „entity.metadata.entity_type“ auf „ASSET“ festgelegt
Objektführung Objekt.entity.asset.product_object_id
Ablaufdatum des Kontos Entität.entity.asset.attribute.label.key/value
Schlechter PwdCount Entität.entity.asset.attribute.label.key/value
Kanonischer Name Unternehmensentität.administrative_domain
Ländercode Objekt.entity.asset.location.country_or_region
Beschreibung entity.entity.metadata.description
Startseite Entität.url
IPv4-Adresse Objekt.entity.asset.ip
IPv6-Adresse Objekt.entity.asset.ip
LetzterBadPasswordPassword Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
letzterLogoff Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
Logo: lastLogon Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
LastLogonDate Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
Ort entity.entity.asset.location.name
Verwaltungstyp Die folgenden Felder sind festgelegt:

entity.entity.user.user_display_name
entity.relations.entity_type auf „USER“
Entität.relations.relationship auf ADMINISTERS
Entität.relations.direction auf UNIDIRECTIONAL festgelegt
Objektkategorie Objekt.entity.asset.category
OperatingSystem Wenn der Name „"Windows"“ enthält, ist das Feld „entity.entity.entity.platform_software.platform“ auf WINDOWS festgelegt.
Betriebssystemdienstpaket Objekt.entity.asset.platform_software.platform_patch_level
OperatingSystemVersion Das Feld „entity.entity.asset.platform_software.platform_version“ ist auf %{OperatingSystem} – %{OperatingSystemVersion} festgelegt.
Kennwort abgelaufen Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
PasswordLastSet Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
Passwort läuft nicht ab Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
Passwort nicht erforderlich Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
Primäre Gruppe Die folgenden Felder sind festgelegt:
- Entität.relations.entity.group.group_display_name
- Entität.relations.entity_type auf GROUP
- Entität.relations.relationship auf MEMBER festgelegt
- Entität.relations.direction auf UNIDIRECTIONAL festgelegt
Dienstprinzipalnamen Wird als Entitäts-.entity.asset.attribute.label.key/value-Paar gespeichert.
Wenn geändert Objekt.entity.asset.attribute.last_update_time
Datum der Erstellung Entität.entity.asset.attribute.creation_time