Return to

109.36. Windows Event Collector (im_wseventing)

This module can be used to collect Windows EventLog from Microsoft Windows clients that have Windows Event Forwarding (WEF) configured. This module takes the role of the collector (Subscription Manager) to accept eventlog records from Windows clients over the WS-Management protocol. WS-Eventing is a subset of WS-Management used to forward Windows EventLog.

The im_mseventlog module requires NXLog to be installed as an agent on the source host. The im_msvistalog module can be configured to pull Windows EventLog remotely from Windows hosts with a NXLog agent running on Windows. The im_wseventing module, however, like im_wmi, can be used on all supported platforms including GNU/Linux systems to remotely collect Windows EventLog without requiring any software to be installed on the source host. Windows clients can be configured through Group Policy to forward EventLog to the system running the im_wseventing module, without the need to list each client machine individually in the configuration.

The WS-Eventing protocol and im_wseventing support HTTPS using X509 certificates and Kerberos to authenticate and securely transfer EventLog.

While there are other products implementing the WS-Eventing protocol (such as IBM WebSphere DataPower), this module was implemented with the primary purpose of collecting and parsing forwarded events from Microsoft Windows. Compatibility with other products has not been assessed.

109.36.1. Kerberos Setup

Follows these steps to set up Windows Event Forwarding with Kerberos.

The steps and examples below assume these systems:

  • Windows domain controller at

  • RHEL Linux node at

  1. Join the Linux node to the domain.

    1. Set the hostname:

      # hostnamectl set-hostname linux
    2. Set the nameserver and static IP address (substitute the correct interface name).

      # nano /etc/sysconfig/network-scripts/ifcfg-enp0s3

      Set to:

  2. Synchronize the time on with For example:

    # ntpdate
  3. Go to the domain controller and create a new user linux (the name of the user should match the hostname of the Linux node).

    1. Go to Administrative ToolsActive Directory Users and Computersad.domain.comUsers.

    2. Right click and choose NewUser.

      1. First name: linux

      2. Full name: linux

      3. User logon name: linux

      4. Set a password on the next page.

      5. Uncheck User must change password at next logon.

      6. Check Password never expires.

    3. Right click on the new user, click Properties, and open the Account tab.

      1. Check This account supports Kerberos AES 128 bit encryption.

      2. Check This account supports Kerberos AES 256 bit encryption.

  4. In the DNS settings on the domain controller, create an A record for

    1. Go to Administrative ToolsDNSForward Lookup

    2. Right click and choose New Host (A or AAAA)….

    3. Add a record with name linux and IP address

  5. Open a Command Prompt on and execute these commands. Use the same <password> as in step 3b.

    > ktpass /princ hosts/ /pass <password> /mapuser DOMAIN\linux -pType KRB5_NT_PRINCIPAL /out hosts-nxlog.keytab /crypto AES256-SHA1
    > ktpass /princ http/ /pass <password> /mapuser DOMAIN\linux -pType KRB5_NT_PRINCIPAL /out nxlog.keytab /crypto AES256-SHA1
  6. Copy the resulting hosts-nxlog.keytab and nxlog.keytab files to

  7. Update the Group Policy on the domain controller.

    1. Run gpedit.msc and go to Computer ConfigurationAdministrative TemplatesWindows ComponentsEvent Forwarding.

    2. Open and enable the Configure target Subscription Manager setting.

    3. Click Show… beside the SubscriptionManagers option.

    4. Type into the Value field: Server=,Refresh=30.

    5. In the Command Prompt, run gpupdate /force.

  8. Set up Kerberos on

    1. Confirm that the Kerberos krb5 client and utility software are installed on the system. The required package can be installed with (for example) yum install krb5-workstation or apt install krb5-user.

    2. Edit the default configuration file at /etc/krb5.conf.

      1. In section [domain_realm], add: = DOMAIN.COM = DOMAIN.COM
      2. In section [realms], add:

        DOMAIN.COM = {
         kdc =
         admin_server =
    3. Use ktutil to merge the two keytab files generated in step 5.

      # ktutil
      ktutil:  rkt /root/hosts-nxlog.keytab
      ktutil:  rkt /root/nxlog.keytab
      ktutil:  wkt /root/nxlog-result.keytab
      ktutil:  q
    4. Validate the merged keytab.

      # klist -e -k -t /root/nxlog-result.keytab
      Keytab name: FILE:/root/nxlog-result.keytab
      KVNO Timestamp           Principal
      ---- ------------------- ------------------------------------------------------
         5 17.02.2016 04:16:37 hosts/ (aes256-cts-hmac-sha1-96)
         4 17.02.2016 04:16:37 http/ (aes256-cts-hmac-sha1-96)
    5. Either copy the keytab into place, or merge if there are already keys in /etc/krb5.keytab.

      • To simply copy the keytab:

        cp /root/nxlog-result.keytab /etc/krb5.keytab
      • To merge the keytab and validate the result:

        # ktutil
        ktutil:  rkt /etc/krb5.keytab
        ktutil:  rkt /root/nxlog-result.keytab
        ktutil:  wkt /etc/krb5.keytab
        ktutil:  q
        # klist -e -k -t /etc/krb5.keytab
        Keytab name: FILE:/etc/krb5.keytab
        KVNO Timestamp           Principal
        ---- ------------------- ------------------------------------------------------
           5 31.12.1969 15:00:00 HTTP/ (aes256-cts-hmac-sha1-96)
           5 17.02.2016 04:20:08 HTTP/ (aes256-cts-hmac-sha1-96)
           5 17.02.2016 04:20:08 hosts/ (aes256-cts-hmac-sha1-96)
           4 17.02.2016 04:20:08 http/ (aes256-cts-hmac-sha1-96)
  9. Make sure the port defined in the im_wseventing configuration is accessible from the Windows clients. The local firewall rules on the Linux node may need to be updated.

  10. Configure and run NXLog. See the configuration example below.

109.36.2. HTTPS Setup

To set up Windows Event Forwarding over HTTPS the following steps are required:

  • X509 certificate generation using either OpenSSL or the Windows certificate manager,

  • configuration of the NXLog im_wseventing module.

  • configuration of Windows Remote Management (WinRM) on each Windows source host,

These steps are covered in greater detail below.

We will refer to the host running NXLog with the im_wseventing module as server. Under Windows the Subscription Manager refers to the same entity since im_wsevening is what manages the subscription. We will use the name client when referring to the Windows hosts sending the logs using WEF.

The client certificate must have the X509 v3 Extended Key Usage: TLS Web Client Authentication extension and the server certificate needs the X509 v3 Extended Key Usage: TLS Web Server Authentication extension. You will likely encounter an error when trying to configure WEF and the connection to the server will fail without these extended key usage attributes. Also make sure that the intended purpose of the certificates are set to Server Authentication and Client Authentication respectively.

When generating the certificates please ensure that the CN in the server certificate subject matches the reverse DNS name, otherwise you may get errors in the Microsoft Windows/Event-ForwardingPlugin/Operational eventlog saying The SSL certificate contains a common name (CN) that does not match the hostname.

Generating the certificates with OpenSSL

If you prefer Windows skip to the next section.

For OpenSSL based certificate generation see the scripts in our public git repository.

Generate the CA certificate and private key:

openssl req -x509 -nodes -newkey rsa:2048 -keyout ca-key.pem -out ca-cert.pem -batch -subj "$SUBJ" -config gencert.cnf
openssl x509 -outform der -in ca-cert.pem -out ca-cert.crt

Generate the client certificate and export it together with the CA in PFX format to be imported into the Windows certificate store:


openssl req -new -newkey rsa:2048 -nodes -keyout client-key.pem -out req.pem -batch -subj "$CLIENTSUBJ" -config gencert.cnf
openssl x509 -req -days 1024 -in req.pem -CA ca-cert.pem -CAkey ca-key.pem -out client-cert.pem -set_serial 01 -extensions client_cert -extfile gencert.cnf
openssl pkcs12 -export -out client.pfx -inkey client-key.pem -in client-cert.pem -certfile ca-cert.pem

Generate the server certificate to be used by the im_wseventing module:

openssl req -new -newkey rsa:2048 -nodes -keyout server-key.pem -out req.pem -batch -subj "$SERVERSUBJ" -config gencert.cnf
openssl x509 -req -days 1024 -in req.pem -CA ca-cert.pem -CAkey ca-key.pem -out server-cert.pem -set_serial 01 -extensions server_cert -extfile gencert.cnf
openssl x509 -outform der -in server-cert.pem -out server-cert.crt

In order to generate the certificates with the correct extensions the following is needed in gencert.cnf:

[ server_cert ]
nsCertType = server
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ client_cert ]
nsCertType = client
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
If you are using an intermediary CA please make sure that the ca-cert.pem file contains—​in correct order—​the public part of every issuer’s certificate. The easiest way to achieve this is to 'cat' the pem certificates together.

If you have more complex requirements follow this guide on how to set up a CA and generate certificates with OpenSSl.

Generating the certificates with the Windows certificate manager

For more information on creating certificates under windows see this document: Request Certificates by Using the Certificate Request Wizard.

Make sure to create the certificates with the required extensions as noted above. Once you have issued the certificates you will need to export the server certificate in PFX format. The PFX must contain the private key also, the password may be omitted. The PFX file can then be converted to the PEM format required by im_wseventing using openssl:

openssl pkcs12 -in server.pfx -nocerts -nodes -out server-key.pem
openssl pkcs12 -in server.pfx -nokeys -nodes -out server-cert.pem

You will also need to export the CA certificate (without the private key) the same way and convert it into ca-cert.pem.

Configure NXLog with the im_wseventing module

You will need to use server-key.pem, server-cert.pem and ca-cert.pem for the HTTPSCertKeyFile, HTTPSCertFile and HTTPSCAFile respectively.

Optionally you can use the QueryXML option to filter on specific channels or events.

See the configuration example below for how your nxlog.conf should look.

Once the configuration is complete you may start the nxlog service.

Configuring WinRM and WEF

  1. Install, configure, and enable Windows Remote Management (WinRM) on each source host.

    1. Make sure the Windows Remote Management (WS-Management) service is installed, running, and set to Automatic startup type.

    2. If WinRM is not already installed, see these instructions on MSDN: Installation and Configuration for Windows Remote Management.

    3. Check that the proper client authentication method (Certificate) is enabled for WinRM. Issue the following command:

      winrm get winrm/config/Client/Auth

      This should produce the following output

       Basic = false
       Digest = true
       Kerberos = true
       Negotiate = true
       Certificate = true
       CredSSP = true [Source="GPO"]

      If Certificate authentication is set to false, it should be enabled with the following:

      winrm set winrm/config/client/auth @{Certificate="true"}

      Windows Remoting does not support event forwarding over unsecured transport (such as HTTP). Therefore it is recommended to disable the Basic authentication:

      winrm set winrm/config/client/auth @{Basic="false"}
    4. Import the client authentication certificate if you used OpenSSL to generate these. In the Certificate MMC snap-in for the Local Computer click More actions - All Tasks - Import…​. Import the client.pfx file. Enter the private key password (if set) and make sure the Include all extended properties check-box is selected.

      After importing is completed, open the Certificates MMC snap-in, select Computer account and double-click on the client certificate to check if the full certificate chain is available and trusted. You may want to move the CA certificate under the Trusted Root Certification Authorities in order to make the client certificate trusted.
    5. Grant the NetworkService account the proper permissions to access the client certificate using the Windows HTTP Services Certificate Configuration Tool (WinHttpCertCfg.exe) and check that the NetworkService account has access to the private key file of the client authentication certificate by running the following command:

      winhttpcertcfg -l -c LOCAL_MACHINE\my -s <certificate subject name>

      If NetworkService is not listed in the output, grant it permissions by running the following command:

      winhttpcertcfg -g -c LOCAL_MACHINE\my -s <certificate subject name> -a NetworkService
    6. In order to access the Security EventLog, the NetworkService account needs to be added to the Event Log Readers group.

    7. Configure the source host security policy to enable event forwarding:

      1. Run the Group Policy MMC snap-in (gpedit.msc) and go to Computer Configuration  Administrative Templates  Windows Components  Event Forwarding.

      2. Right-click the SubscriptionManager setting and select Properties. Enable the SubscriptionManager setting, and click Show to add a server address.

      3. Add at least one setting that specifies the NXLog collector system. The SubscriptionManager Properties window contains an Explain tab that describes the syntax for the setting. If you have used the script it should print the subscription manager string that has the following format:

        Server=HTTPS://<FQDN of im_wseventing><:port>/wsman/,Refresh=<Refresh interval in seconds>, IssuerCA=<certificate authority certificate thumbprint>

        An example would be as follows:

      4. To find the IssuerCA fingerprint, open MMC, add the Certificates snap-in, select the Local Computer account find the Issuing CA certificate. Copy the Thumbprint from the Details tab. Please make sure to eliminate spaces and the invisible non-breaking space that is before the first character of the thumbprint on Windows 2008.

      5. After the SubscriptionManager setting has been added, ensure the policy is applied by running:

        gpupdate /force
      6. At this point the WinRM service on the Windows client should connect to NXLog and there should be a connection attempt logged in nxlog.log and you should soon start seeing events arriving.

109.36.3. Forwarding Security Events

In adherence to C2-level Security, access to audit data of security-related events is limited to authorized administrators. WinRM runs as a network service and may not have access to the Security log, as such it may not forward Security events. To give it access to the Security Log:

  1. Open Group Policy Editor by running gpedit.msc.

  2. Go to Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsEvent Log ServiceConfigure Log Access.

  3. In the Configure Log Access policy setting, enter:

  4. Run gpupdate /force to apply changes.

109.36.4. Troubleshooting

WEF if not easy to configure and there may be many things that can go wrong. To troubleshoot WEF you should check the Windows Eventlog under the following channels:

  • Applications and Services Logs/Microsoft Windows/Event-ForwardingPlugin

  • Applications and Services Logs/Microsoft Windows/Windows Remote Management

  • Applications and Services Logs/Microsoft Windows/CAPI2

The CN in the server certificate subject must match the reverse dns, otherwise you may get errors in the Microsoft Windows/Event-ForwardingPlugin/Operational eventlog saying The SSL certificate contains a common name (CN) that does not match the hostname. Also in that case the WinRM service may want to use a CRL url to download the revocation list. If it cannot check the CRL there will be error messages under Applications and Services Logs/Microsoft Windows/CAPI2 such as this:

<Result value="80092013">The revocation function was unable to check
revocation because the revocation server was offline.</Result>

In our experience if the FQDN and the reverse DNS of the server is properly set up it shouldn’t fail with the CRL check.

Unfortunately the diagnostic messages in the Windows Eventlog are in some cases rather sloppy. You may see messages such as The forwarder is having a problem communicating with the subscription manager at address https://nxlog:5985/wsman/. Error code is 42424242 and the Error Message is . Note the empty error message. Other than guessing you may try looking up the error code on the internet…​

If the IssuerCA thumbprint is incorrect or it can’t locate the certificate in the certificate store then the above error will be logged in the Windows EventLog with Error code 2150858882.

The Refresh interval should be set to a higher value (e.g. Refresh=1200), in the GPO Subscription Manager settings otherwise the windows client will reconnect too frequently resulting in a lot of connection/disconnection messages in nxlog.log.

By default the module does not log connection attempts which would be otherwise useful for troubleshooting purposes. This can be turned on with the LogConnections configuration directive. The windows Event Forwarding service may disconnect during the TLS handshake with the following message logged in nxlog.log when LogConnections is enabled. This is normal as long as there is another connection attempt right after the disconnection.

2017-09-28 12:16:01 INFO connection accepted from
2017-09-28 12:16:01 ERROR im_wseventing got disconnected during SSL handshake
2017-09-28 12:16:01 INFO connection accepted from

See the article on Technet titled Windows Event Forwarding to a workgroup Collector Server for further instructions and troubleshooting tips.

109.36.5. Configuration

The im_wseventing module accepts the following directives in addition to the common module directives. The Address and ListenAddr directives are required.


This mandatory directive accepts a URL address. This address is sent to the client to notify it where the events should be sent. For example, Address https://nxlogserver.domain.corp:5985/wsman.


This mandatory directive specifies the address of the interface where the module should listen for client connections. Normally the any address is used.


This boolean directive defines whether the module should store raw XML-formatted event data. If set to TRUE, the module stores raw XML data in the $EventXML field. By default, the value is set to FALSE, and the $EventXML field is not added to the event record.


This optional directive specifies the reconnection interval. The default value is PT60.0S (60 seconds).


This optional directive specifies the maximum number of reconnection attempts. The default is 5 attempts. If the client exceeds the retry count it will consider the subscription to be stale and will not attempt to reconnect.


This optional directive can be used to specify a duration after which the subscription will expire, or an absolute time when the subscription will expire. By default, the subscription will never expire.


Heartbeats are dummy events that do not appear in the output. These are used by the client to signal that logging is still functional if no events are generated during the specified time period. The default heartbeat value of PT3600.000S may be overridden with this optional directive.


This boolean directive specifies that the remote connection should be allowed without certificate verification. If set to TRUE the remote will be able to connect with an unknown or self-signed certificate. The default value is FALSE: all HTTPS connections must present a trusted certificate.


This specifies the path to a directory containing certificate authority (CA) certificates, which will be used to check the certificate of the remote HTTPS client. The certificate filenames in this directory must be in the OpenSSL hashed format. A remote’s self-signed certificate (which is not signed by a CA) can also be trusted by including a copy of the certificate in this directory.


This specifies the path of the certificate authority (CA) certificate, which will be used to check the certificate of the remote HTTPS client. To trust a self-signed certificate presented by the remote (which is not signed by a CA), provide that certificate instead.


This specifies the path of the certificate file to be used for the HTTPS handshake.


This specifies the path of the certificate key file to be used for the HTTPS handshake.


This specifies the path to a directory containing certificate revocation lists (CRLs), which will be consulted when checking the certificate of the remote HTTPS client. The certificate filenames in this directory must be in the OpenSSL hashed format.


This specifies the path of the certificate revocation list (CRL) which will be consulted when checking the certificate of the remote HTTPS client.


With this directive, a password can be supplied for the certificate key file defined in HTTPSCertKeyFile. This directive is not needed for passwordless private keys.


This optional directive can be used to set the permitted SSL cipher list, overriding the default. Use the format described in the ciphers(1ssl) man page.


This directive can be used to set the allowed SSL/TLS protocol(s). It takes a comma-separated list of values which can be any of the following: SSLv2, SSLv3, TLSv1, TLSv1.1, and TLSv1.2. By default, the TLSv1, TLSv1.2, and TLSv1.2 protocols are allowed. Note that the OpenSSL library shipped by Linux distributions may not support SSLv2 and SSLv3, in which case these will not work even if enabled with HTTPSSSSLProtocol.


This boolean directive can be used to turn on logging of connections. Since WEF connections can be quite frequent and excessive it could generate a lot of noise. On the other hand it can be useful to troubleshoot clients. This is disabled by default.


This optional directive specifies the maximum number of event records to be batched by the client. If this is not specified the default value is decided by the client.


This optional directive can be used to set a limit on the size of the allowed responses, in bytes. The default size is 153600 bytes. Event records exceeding this size will be dropped by the client and replaced by a drop notification.


This optional directive specifies the maximum amount of time allowed to elapse for the client to batch events. The default value is PT30.000S (30 seconds).


This specifies the port on which the module will listen for incoming connections. The default is port 5985.


This boolean directive allows you to enable data compression when sending data over the network. The compression mechanism is based on the zlib compression library. If the directive is not specified, it defaults to FALSE (the compression is disabled).

Some Linux packages (for example, Debian) use the OpenSSL library provided by the OS and may not support the zlib compression mechanism. The module will emit a warning on startup if the compression support is missing. The generic deb/rpm packages are bundled with a zlib-enabled libssl library.

This directive specifies the query for pulling only specific EventLog sources. See the MSDN documentation about Event Selection. Note that this directive requires a single-line parameter, so multi-line query XML should be specified using line continuation:

Query <QueryList>                                              \
        <Query Id='1'>                                         \
          <Select Path='Security'>*[System/Level=4]</Select>   \
        </Query>                                               \

This directive is the same as the Query directive above, except it can be used as a block. Multi-line XML queries can be used without line continuation, and the XML Query can be directly copied from Event Viewer.

    <Query Id='1'>
      <Select Path='Security'>*[System/Level=4]</Select>

The default value of NXLog Subscription may be overridden by with this optional directive. This name will appear in the client logs.

109.36.6. Fields

The following fields are used by im_wseventing.

The actual fields generated will vary depending on the particular event’s source data.

$raw_event (type: string)

A string containing the $EventID, $EventType, $EventTime, $Hostname, and $Message from the event.

$ActivityID (type: string)

A globally unique identifier for the current activity.

$Channel (type: string)

The Channel of the event source (for example, Security or Application).

$EventData (type: string)

Event-specific data. This field is mutually exclusive with $UserData.

$EventID (type: integer)

The event ID specific to the event source.

$EventTime (type: datetime)

The timestamp that indicates when the event was logged.

$EventType (type: string)

The type of the event, which is a string describing the severity. This is translated to its string representation. Possible values are: CRITICAL, ERROR, AUDIT_FAILURE, AUDIT_SUCCESS, INFO, WARNING, and VERBOSE.

$EventXML (type: string)

The raw event data in XML format. This field is available if the module’s CaptureEventXML directive is set to TRUE.

$ExecutionProcessID (type: integer)

The ID identifying the process that generated the event.

$ExecutionThreadID (type: integer)

The ID identifying the thread that generated the event.

$Hostname (type: string)

The name of the computer that generated the event.

$Keywords (type: string)

The keywords used to classify the event, as a hexadecimal number.

$Level (type: string)

The level of the event as a string, resolved from $LevelValue. Possible values include: Success, Information, Warning, Error, Audit Success, and Audit Failure.

$LevelValue (type: integer)

The level of the event.

$Message (type: string)

The message from the event.

$MessageID (type: string)

The unique identifier of the message.

$Opcode (type: string)

The Opcode string resolved from OpcodeValue.

$OpcodeValue (type: integer)

The Opcode number of the event as in EvtSystemOpcode.

$param1 (type: string)

Additional event-specific data ($param1, $param2, and so on).

$ProviderGuid (type: string)

The globally unique identifier of the event’s provider. This corresponds to the name of the provider in the $SourceName field.

$RecordNumber (type: integer)

The number of the event record.

$Severity (type: string)

The normalized severity name of the event. See $SeverityValue.

$SeverityValue (type: integer)

The normalized severity number of the event, mapped as follows.

Event Log Severity Normalized Severity

0/Audit Success


0/Audit Failure












$SourceName (type: string)

The event source which produced the event.

$Task (type: string)

The task defined in the event.

$UserData (type: string)

Event-specific data. This field is mutually exclusive with $EventData.

$UserID (type: string)

The Security Identifier (SID) of the account associated with the event.

$Version (type: integer)

The version number of the event.

109.36.7. Examples

Example 575. Collecting Forwarded Events Using Kerberos

This example collects Windows EventLog data using Kerberos.

nxlog.conf [Download file]
SuppressRepeatingLogs FALSE

<Extension json>
    Module              xm_json

<Input wseventin>
    Module              im_wseventing
    Address             http://LINUX.DOMAIN.COM:80/wsman
    Port                80
    SubscriptionName    test
    Exec                log_info(to_json());
            <Query Id="0" Path="Application">
                <Select Path="Application">*</Select>
                <Select Path="Security">*</Select>
                <Select Path="Setup">*</Select>
                <Select Path="System">*</Select>
                <Select Path="ForwardedEvents">*</Select>
                <Select Path="Windows PowerShell">*</Select>
Example 576. Collecting Forwarded Events Using HTTPS

This example Input module instance collects Windows EventLog remotely. Two EventLog queries are specified, the first for hostnames matching foo* and the second for other hostnames.

nxlog.conf [Download file]
<Input wseventing>
    Module          im_wseventing
    Port            5985
    HTTPSCertFile   %CERTDIR%/server-cert.pem
    HTTPSCertKeyFile %CERTDIR%/server-key.pem
    HTTPSCAFile     %CERTDIR%/ca.pem
            <Query Id="0" Path="Application">
                <Select Path="Application">*</Select>
        <Query Id="0" Path="Application">
          <Select Path="Application">*</Select>
          <Select Path="Microsoft-Windows-Winsock-AFD/Operational">*</Select>
          <Select Path="Microsoft-Windows-Wired-AutoConfig/Operational">*</Select>
          <Select Path="Microsoft-Windows-Wordpad/Admin">*</Select>
          <Select Path="Windows PowerShell">*</Select>