Events Forwarding not happening

[rvenkatasubbaaravind]

We have 2 machines on the same network

1. Ubuntu machine (OpenWEC server)
2. MSAD server machine (Event Forwarder)

We are trying to read the data from the server security events .

Steps we followed

1. Created new user with a SPN and a dns entry for OpenWEC server wec.domain.com
2. Generated KeyTab file and copied to the OpenWEC server machine . Verified with kinit and on klist we are able to see the changes
3. For the openwec.conf.toml file we made changes to the hostname as wec.domain.com and to the service_principal_name, we have copied the 01-simple.toml as is.
4. We did the event forwarding on the Event Forwarder machine as mentioned on the docs .

Observations

1. We are able to call the wec.domain.com:5985 from the Event Forwarder machine .
2. I am not noticing any further logs on the OpenWEC server container logs

root@ip-172-31-21-11:~/data# docker run -v /root/data:/etc/ -v /root/data/conf:/etc/openwec.d/ -p 5985:5985 -p 5986:5986 ghcr.io/cea-sec/openwec:latest
+ ./openwec db init
+ '[' -d /etc/openwec.d/ ']'
+ ./openwec subscriptions load /etc/openwec.d
+ Load subscription simple
+ exec ./openwecd
2025-03-04T14:23:31.736350624+00:00 INFO server - Monitoring thread started
2025-03-04T14:23:31.737412781+00:00 INFO server - Server settings: Server { db_sync_interval: None, flush_heartbeats_interval: None, heartbeats_queue_size: None, node_name: None, keytab: Some("/etc/openwec.keytab"), tcp_keepalive_time: None, tcp_keepalive_intvl: None, tcp_keepalive_probes: None }
2025-03-04T14:23:31.737478421+00:00 INFO server::subscription - reload_subscriptions task started
2025-03-04T14:23:31.737520928+00:00 INFO server::heartbeat - Heartbeat task started
2025-03-04T14:23:31.737692227+00:00 INFO server - Server listenning on 0.0.0.0:5985
2025-03-04T14:23:31.739247697+00:00 INFO server::subscription - Subscription simple has been created
2025-03-04T14:23:31.739699311+00:00 INFO server::drivers::files - Files output thread started

Can you check if we miss any steps

[MrAnno]

Hi,

To investigate this, you may want to enable debug logging in OpenWEC.

The first step would be to check the error messages in the following 2 channels (Event Viewer) on the Windows machine:

• Applications and Services Logs\Microsoft\Windows\Eventlog-ForwardingPlugin
• Applications and Services Logs\Microsoft\Windows\Windows Remote Management

[rvenkatasubbaaravind]

Openwec server looks like not connected

$ ./openwec stats
Subscription simple (e493fa95-4810-4c61-8ac7-7fa8d028a144) - *
- 0 machines ever seen
- 0 active machines (event received since 2025-03-04T16:16:17+00:00)
- 0 alive machines (heartbeat received since 2025-03-04T16:16:17+00:00 but no events)
- 0 dead machines (no heartbeats nor events since 2025-03-04T16:16:17+00:00)

[MrAnno]

OpenWEC implements the source-initiated mode of event forwarding, which means that Windows machines are responsible for connecting to the OpenWEC server to query their subscriptions.

Please check the mentioned channels in Event Viewer.

[rvenkatasubbaaravind]

Even after joining the domain controller we are getting the error

ip:53262 - - [2025-03-05T17:43:19.447276567+00:00] "/test" 401 0.130
2025-03-05T17:43:19.447235915+00:00 WARN server - Authentication failed for ip:53262 (POST:/test): Other(Failed to perform Kerberos operation  Caused by:     Unspecified GSS failure.  Minor code may provide more information (Service key not available))

what are we missing from the MSAD server Machine ?

[vruello]

There is a problem related to Kerberos authentication. Make sure that the collectors.authentication.service_principal_name in the openwec configuration matches at least one entry in the keytab set in server.keytab. It may be case sensitive.

Can you use the keytab to authenticate as the service? You can try that with kinit -kt <keytab> <spn>, where keytab is your keytab file and spn is the service principal name provided in openwec configuration.If it doesn't work, you can get additional information using the environment variable KRB5_TRACE=/dev/stderr.

[rvenkatasubbaaravind]

Within the container? , the container is readonly we can't add any external package and test ..

There is a problem related to Kerberos authentication. Make sure that the collectors.authentication.service_principal_name in the openwec configuration matches at least one entry in the keytab set in server.keytab. It may be case sensitive.

Can you use the keytab to authenticate as the service? You can try that with kinit -kt <keytab> <spn>, where keytab is your keytab file and spn is the service principal name provided in openwec configuration.If it doesn't work, you can get additional information using the environment variable KRB5_TRACE=/dev/stderr.

[vruello]

You can run the kinit command outside of the container, as long as you have access to the keytab file.

[rvenkatasubbaaravind]

I am able to do kinit from outside the container , i can even see the klist

After adding this KRB5_TRACE=/dev/stderr

seeing this issue

[1] 1741225133.035606: Retrieving HTTP/[email protected] from FILE:/etc/openwec.keytab (vno 0, enctype 0) with result: 0/Success [1] 1741225133.035607: Retrieving HTTP/[email protected] from FILE:/etc/openwec.keytab (vno 6, enctype rc4-hmac) with result: -1765328203/No key table entry found for HTTP/[email protected] [1] 1741225133.035608: Failed to decrypt AP-REQ ticket: -1765328339/No key table entry found for HTTP/[email protected]

They key what we got genearted on windows machine is vno 0 and etype 0x12 (AES256-SHA1)

[rvenkatasubbaaravind]

One more thing to clarify do the linux machine need to join the domain ?

[vruello]

It seems that the client tries to authenticate using rc4-hmac, for which you don't have any entry in the keytab. Could you check the value of the attribute msDS-SupportedEncryptionTypes of the wec service account? Your keytab should contain an entry for all these algorithms (you can also choose to remove some of them, such as rc4, by editing the object). ktpass (windows) will generate an entry for all these algorithms unless you specify /crypto yourself.

Also, don't set kvno to 0. ktpass (windows) will set for you the appropriate value. You can also retrieve it by querying the msDS-KeyVersionNumber attribute of the wec service account.

Use klist -kte <keytab> to visualize the entries of your keytab.

One more thing to clarify do the linux machine need to join the domain ?

I don't know what you mean by Linux machine "joined" in the domain, but no, you only need a keytab with entries for the spn.