NXLog Docs

Windows Event Collector (im_wseventing)

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

In comparison, the im_msvistalog module can be configured to collect Windows Event Logs both locally or remotely, however it requires an NXLog agent running on Windows. More information on this can be found in the topic on Collecting Event Log Data. The im_wseventing module can be used on all supported platforms including GNU/Linux systems to remotely collect Windows Event Logs without requiring any additional software to be installed on the source host.

To examine the supported platforms, see the list of installer packages in the Available Modules chapter.

Overview of Windows Event Forwarding

WEF is a service which enables the forwarding of administrative and operational Event Logs from a Windows server to a central location. There are two roles in a WEF setup:

  • the Windows Event Collector (WEC), also known as a Subscription Manager, which is a server configured to receive events;

  • the WEF client, also known as a forwarder, which is a machine configured to forward events to the collector.

The link between the two is known as a subscription and it can be configured either as a push or pull service.

NXLog can take the role of a WEC by configuring the im_wseventing module to collect events forwarded to it, thus using the push method. Windows machines are then configured as WEF clients, forwarding events to NXLog. The advantage of using this method is that clients can be configured to forward their events via Group Policy, removing the overhead of having to manage a list of clients from which events are to be collected.

The connection between the WEC and the client is mutually authenticated and encrypted using Kerberos by default. In cases where Kerberos authentication cannot be used, an HTTPS option using certificate based authentication is also possible. NXLog can be configured to use either of these authentication methods.

In this documentation we refer to the machine where NXLog is installed as the WEC server, and the Windows machine forwarding events to it as the WEF client.

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

Configuring Kerberos authentication for use with WEF clients

This section explains how to configure a Microsoft Active Directory domain user to be used with Kerberos authentication on a Linux machine. Once these steps are complete, NXLog can be configured as a Windows Event Collector with WEF clients forwarding events to it.

The steps and examples below assume the following values:

  • example.com is the FQDN of the Active Directory domain.

  • EXAMPLE is the name of the Active Directory domain.

  • linux is the name of the Linux WEC server.

WEC server prerequisites

For Kerberos authentication to work successfully, the Linux machine acting as a WEC server must meet the following prerequisites:

  • The OS must return the correct hostname.

  • The machine must be configured with a static IP address.

  • DNS settings must point to the same DNS server used in the Active Directory domain.

  • The time must be synchronized with the Active Directory domain.

Refer to the documentation of your operating system for instructions how to configure and verify these settings.

Create and map the Active Directory domain user

  1. On the Active Directory domain controller, create a new user as follows:

    1. The account name should match the hostname of the Linux WEC server.

    2. Set a password for the user.

    3. Disable the User must change password at next logon option.

    4. Enable the Password never expires option.

    5. The account should have the Kerberos AES 128 bit encryption and Kerberos AES 256 bit encryption options enabled.

  2. On the DNS server, create an A record for the Linux WEC server with an associated PTR record for reverse lookup.

  3. On the Active Directory domain controller, open a command prompt and execute these commands. Use the same <password> that was specified when the above user was created. These commands map the domain account to the Kerberos principal names and generate two keytab files containing the shared secret.

    > ktpass /princ hosts/linux.example.com@EXAMPLE.COM /pass <password> /mapuser DOMAIN\linux -pType KRB5_NT_PRINCIPAL /out hosts-nxlog.keytab /crypto AES256-SHA1
    > ktpass /princ http/linux.example.com@EXAMPLE.COM /pass <password> /mapuser DOMAIN\linux -pType KRB5_NT_PRINCIPAL /out nxlog.keytab /crypto AES256-SHA1

    Refer to the Microsoft documentation for more information on the ktpass tool.

  4. Copy the resulting hosts-nxlog.keytab and nxlog.keytab files to the Linux host.

Configure Kerberos on the WEC server

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

  2. Edit the default Kerberos configuration file, usually located at /etc/krb5.conf.

    1. In section [domain_realm], add:

      .example.com = EXAMPLE.COM
      example.com = EXAMPLE.COM
    2. In section [realms], add:

      EXAMPLE.COM = {
       kdc = example.com
       admin_server = example.com
    3. Use ktutil to merge the two keytab files generated above.

      # 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.01.2021 04:16:37 hosts/linux.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
         4 17.01.2021 04:16:37 http/linux.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
    5. Either copy the keytab into place, or merge it if there are already keys in /etc/krb5.keytab.

      • To 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
        ---- ------------------- ------------------------------------------------------
           <other entries>
           5 17.01.2021 04:20:08 hosts/linux.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
           4 17.01.2021 04:20:08 http/linux.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      • Verify that the access permissions of the /etc/krb5.keytab file allow the user that NXLog is running under to read it. If not, Kerberos authentication will fail as described in the Troubleshooting section.

  3. Test that the authentication with Active Directory is working successfully when using the keytab. Run the following command on the Linux WEC server and if the configuration is correct a ticket-granting ticket (TGT) will be created and cached. This step should be executed with the user that NXLog is running under, by default the nxlog user.

    # kinit -kt /etc/krb5.keytab http/linux.example.com@EXAMPLE.COM
  4. Verify the ticket was obtained by running klist with the same user as the previous step:

    # klist
    Ticket cache: KCM:0
    Default principal: http/linux.example.com@EXAMPLE.COM
    Valid starting     Expires            Service principal
    28/01/21 11:41:44  28/01/21 21:41:44  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    	renew until 04/02/21 11:41:44
  5. Configure and run NXLog. See the configuration example below.

  6. Make sure the port defined in the im_wseventing configuration is accessible from the WEF clients. The local firewall rules on the Linux WEC server may need to be updated.

Configure the WEF Client

In this example, WEF is enabled on a single Windows node by editing the local policy of the server. To enable WEF on multiple nodes, a group policy on the domain should be configured.

  1. Run gpedit.msc and go to Computer Configuration > Administrative Templates > Windows Components > Event 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=http://linux.example.com:80,Refresh=30.

  5. Open command prompt and run gpupdate /force.

  6. At this point the WinRM service on the Windows client should connect to NXLog. If LogConnections is set to TRUE a connection attempt should be logged in nxlog.log and you should soon start seeing events arriving.

The Refresh interval represents the time in seconds and on production systems should be set to a higher value (e.g. Refresh=1200). When the Windows client is set to reconnect too frequently it will result in a lot of connection/disconnection messages in nxlog.log.

Configuring WEF to use HTTPS

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 client.

These steps are covered in greater detail below.

We will refer to the host running NXLog with the im_wseventing module as WEC server. We will use the name WEF client when referring to the Windows hosts sending the logs using WEF.

Certificate requirements:

  • The WEF client certificate must have the X509 v3 Extended Key Usage: TLS Web Client Authentication extension.

  • The WEC server certificate must have the X509 v3 Extended Key Usage: TLS Web Server Authentication extension.

  • Make sure that the intended purpose of the certificates are set to Client Authentication and Server Authentication respectively.

If these extended key usage attributes are not set you will likely encounter an error when trying to configure WEF and the connection to the server will fail.

Generating the certificates with OpenSSL

To use the Windows certificate manager skip to the next section.

To facilitate the generation of certificates using OpenSSL, the following scripts are available in our public git repository:

  • genca.sh - generates the CA certificate and private key.

  • gencert-client.sh - generates the WEF client certificate and exports it together with the CA in PFX format to be imported into the Windows certificate store.

  • gencert-server.sh - generates the WEC server certificate to be used by the im_wseventing module.

Refer to the readme file for instructions on the scripts.

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

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.

For 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 WEC server certificate in PFX format. The PFX must contain the private key, 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

Configure WinRM on the client for certificate-based authentication and enable Windows Event Forwarding. These steps can be automated for ease of deployment across multiple clients. See the example PowerShell script in our public git repository.

  1. Install, configure, and enable Windows Remote Management (WinRM) on each WEF client.

    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 command:

      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 CA and WEF client certificates if you used OpenSSL to generate these.

      1. Open the Certificate MMC snap-in for the Local Computer (certlm.msc).

      2. Right click on Trusted Root Certification Authorities and select 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.

      3. Repeat the previous step to import the certificate to the Personal certificate store.

        After importing is complete, expand Personal > Certificates and double-click on the WEF client certificate to check if the full certificate chain is available and trusted.
    5. Grant the NetworkService account the proper permissions to access the WEF client certificate by 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>

      Where LOCAL\my refers to the Personal certificate store of the Local Computer and <certificate subject name> is the CN value that was specified when creating the WEF client certificate. For example:

      winhttpcertcfg -l -c LOCAL_MACHINE\my -s winclient.example.com

      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 forward Security events, the Network Service account needs to be given access to the Secuity Event Log. Refer to the section on [forwarding-events-from-the-security-log].

    7. Configure the policy on the WEF client to enable event forwarding. In this example, WEF is enabled on a single Windows node by editing the local policy of the server. To enable WEF on multiple nodes, a group policy on the domain should be configured.

      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 Configure target Subscription Manager setting and select Properties. Enable the setting, and under Options click the Show button to add a server address.

      3. Add at least one setting that specifies the NXLog WEC server. The SubscriptionManager properties window contains a Help pane that describes the syntax for the setting. If you have used the gencert-server.sh script the subscription manager string should be in 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 Certificates MMC snap-in, expand Local Computer > Personal > Certificates and open the CA certificate. Copy the Thumbprint from the Details tab. Please make sure to eliminate spaces and the invisible non-breaking space that may be present 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 WEF client should connect to NXLog. If LogConnections is set to TRUE a connection attempt should be logged in nxlog.log and you should soon start seeing events arriving.

Forwarding events from the Security log

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 by default does not have access to the Security log, therefore it will not be able to forward Security events.

To give it access to the Security log on Windows 2008 and newer the Network Service account should be added to the Event Log Readers group.

To give it access on older versions of Windows:

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

  2. Go to Computer Configuration > Administrative Templates > Windows Components > Event Log Service > Security.

  3. Right click on the Configure Log Access and click on Edit

  4. Enable the policy and under Log Access enter:

  5. Run gpupdate /force to apply changes.


WEF if not easy to configure and there may be many things that can go wrong. To troubleshoot WEF, check the Windows Event Log 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 Operational log for these channels is enabled by default. The Analytic and Debug logs may also prove useful and can be enabled from the Windows Event Viewer as follows:

  1. From the menu click on View and select Show Analytic and Debug Logs.

  2. Under each of these channels, click on the Debug log and in the Actions pane select Enable Log.

  3. Repeat the previous step for the Analytic log when available.

Unfortunately the diagnostic messages in the Windows Event Log may not always be helpful and in some cases may even be missing. In such cases searching for the error code on the internet may point to more useful information. This section provides troubleshooting tips for commonly encountered issues.

The SSL certificate name does not match the hostname

The WEF client fails to connect to the WEC server and the Microsoft/Windows/Event-ForwardingPlugin/Operational Event Log contains the following error:

The SSL certificate contains a common name (CN) that does not match the hostname.

This error occurs when the CN in the WEC server certificate does not match the reverse DNS. Run nslookup <server_ip> on the client and verify that the correct name for the server is returned. You can use the openssl tool on the WEC server to verify that the subject CN matches the same name by using the following command:

openssl x509 -in server-cert.pem -text -noout

If the FQDN and the reverse DNS of the WEC server are not properly set up, the WinRM service may fail to connect to the CRL URL to download the revocation list. In that case an error messages will be logged under Applications and Services Logs/Microsoft/Windows/CAPI2 as follows:

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

The WEF client fails to forward events to the Subscription Manger

If a secure connection cannot be established between the WEF client and the WEC server, the Microsoft/Windows/Event-ForwardingPlugin/Operational Event Log may contain the following error:

The forwarder is having a problem communicating with the subscription manager
at address https://nxlogserver.example.com:5985/wsman/.
Error code is <error_code> and the Error Message is <error_message>.

Note that the error message can sometimes be empty.

When using HTTPS, this event is logged with Error code 2150858882 when a certificate matching the specified IssuerCA thumbprint is not found. Verify that the thumbprint specified does not have any invisible characters as explained in this Microsoft support article. Additionally, check that the thumbprint specified is for the CA certificate and not the WEF client, and that it can be found under Local Computer > Personal in the Certificates MMC snap-in.

When using Kerberos, this event may be logged with Error code 2150858999 and the following message:

The WinRM client cannot process the request.
It cannot determine the content of the HTTP response from the destination computer.

This error can occur when authentication fails on the WEC server side and NXLog responds with a 400 Bad Request. In such case the NXLog log file contains the following error:

ERROR [im_wseventing|wsevents] GSS-API error gss_accept_sec_context - type: major code: 851968, msg: Unspecified GSS failure.  Minor code may provide more information
ERROR [im_wseventing|wsevents] GSS-API error gss_accept_sec_context - type: minor code: -1765328203, msg: Key table entry not found
ERROR [im_wseventing|wsevents] [im_wseventing.c:1898/im_wseventing_create_kerb_auth_response()] Internal error

Carefully revise the steps required to [configuring-kerberos-authentication-for-use-with-wef-clients]. In particular make sure that the hostname on the WEC server is resolved to the same hostname as specified in the keytab principal. Run nslookup <server_ip> on the WEC server and verify that the name returned is correct. For example if the principal in the keytab is specified as:


Then the name returned by nslookup should be linux.example.com.

This error can also occur if the user that NXLog is running under is not able to read the keytab file. Check the access permissions of /etc/krb5.keytab and verify that they allow at least Read access to the user. By default NXLog runs with the nxlog user. If the keytab file was manually copied, the access permissions may have been changed.

Configuring im_wseventlog to log connections

By default the module does not log connection attempts which would otherwise be useful for troubleshooting purposes. This can be turned on with the LogConnections directive. Note that 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.

INFO connection accepted from
ERROR im_wseventing got disconnected during SSL handshake
INFO connection accepted from

See the Microsoft documentation on Windows Event Forwarding to a workgroup Collector Server for further instructions and troubleshooting tips.


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 WEF client to notify it where the events should be sent. For example, Address https://nxlogserver.example.com:5985/wsman.


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

When the Host directive is used with a hostname instead of an IP address, the the hostname will be resolved to an IP address for each new connection. If a resolver, e.g. DNS, returns multiple IP addresses, the module will connect to the first IP address. If a single output instance is configured with multiple Host directives or the resolver returns multiple addresses for a name, these hosts are accessed in failover mode. If a Host directive is configured with a hostname, the product performs a name lookup and establishes the connection to the first reachable address in the returned set of addresses. The module will remain connected to that address until it is stopped, or the connection is severed. DNS changes are therefore not picked up by the module without intervention. If the connection fails to the first address of the set, the module will attempt to connect to the next address, until it reaches the end of the set of addresses. Then it performs a lookup on the next Host directive, if so configured. Once all options are exhausted, the module will start over from the first Host directive, cycling through them again until connection can be reestablished.

When the ListenAddr (or similar) directive specifies a hostname, the module binds to the first IP address that is exposed by the system for that hostname. On most systems that support IPv6, this address will be an IPv6 address. This means that client applications and the systems they run on will also need to have IPv6 support enabled, and must be able to connect to the same IPv6 address. NXLog output modules achieve this requirement through failover. For third-party client applications, the configuration details are application-specific but they should have the ability to detect which IP address the server is listening on when using a hostname to connect.

For client applications that don’t support IPv6, to avoid the behavior described above the ListenAddr directive of the listening module may be set to an IPv4 address e.g.

Alternatively, the server-side system may be configured to prioritize IPv4 addresses for the hostname specified by the ListenAddr directive, although this is a more complicated and potentially intrusive approach. On most Linux-based systems, this can be achieved through the /etc/gai.conf configuration file. On BSD-based systems, the ip6addrctl command can be used. Windows is more limited and can only be configured to prioritize IPv4 over IPv6 addresses for ALL hostnames resolved on the system, by setting the following registry value to 0x20:


For more information see the Microsoft documentation on Configuring IPv6 in Windows for advanced users.

This limitation will be addressed in a future release by making listening modules bind to all available IPv4/IPv6 addresses that a hostname resolves to.


If this boolean directive is set to TRUE, names of fields parsed from the <EventData> portion of the event XML will be prefixed with EventData.. For example, $EventData.SubjectUserName will be added to the event record instead of $SubjectUserName. The same applies to <UserData>. This directive defaults to FALSE: field names will not be prefixed.


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: 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 WEF 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 WEF 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 optional directive specifies the certificate thumbprint of the certificate authority (CA), which is used to look up the CA certificate from the Windows certificate store. The hexadecimal fingerprint string can be copied straight from Windows Certificate Manager (certmgr.msc), whitespaces are automatically removed. This directive is only supported on Windows. This directive and the HTTPSCADir and HTTPSCAFile directives are mutually exclusive.


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 optional directive specifies the certificate thumbprint to be used for the SSL handshake. The hexadecimal fingerprint string can be copied straight from Windows Certificate Manager (certmgr.msc), whitespaces are automatically removed. This directive is only supported on Windows. This directive and the HTTPSCertFile and HTTPSCertKeyFile directives are mutually exclusive.


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 optional directive can be used to set the permitted cipher list for TLSv1.3. Use the same format as in the HTTPSSSLCipher directive. Refer to the OpenSSL documentation for a list of valid TLS v1.3 cipher suites. The default value is:


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 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, TLSv1.2 and TLSv1.3. By default, the TLSv1.2 and TLSv1.3 protocols are allowed. Note that the OpenSSL library shipped by Linux distributions may not support SSLv2 and SSLv3, and these will not work even if enabled with this directive.


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 WEF 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 directive specifies the query for pulling only specific Event Log 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.

    <!-- XML-style comments can
         span multiple lines in
         QueryXML blocks like this.
    <Query Id='1'>
      <Select Path='Security'>*[System/Level=4]</Select>
Commenting with the # mark does not work within multi-line Query directives or QueryXML blocks. In this case, use XML-style comments <!-- --> as shown in the example above. Failure to follow this syntax for comments within queries will render the module instance useless. Since NXLog does not parse the content of QueryXML blocks, this behavior is expected.

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


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.


Example 1. Collecting forwarded events using Kerberos

This example collects Windows Event Log data using Kerberos authentication.

SuppressRepeatingLogs FALSE

<Extension json>
    Module              xm_json

<Input wseventin>
    Module              im_wseventing
    Address             http://LINUX.EXAMPLE.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 2. Collecting forwarded events using HTTPS

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

<Input wseventing>
    Module              im_wseventing
    Port                5985
    Address             https://linux.example.com:5985/wsman
    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>