openwec openwec has connection issues with windows 2025

hello, we were able to implement openwec with windows 2022 without any problems, however, when we try to subscribe a windows 2025, we are seeing issues in the windows client like the below:

The forwarder is having a problem communicating with subscription manager at address http://openwec:5985/server. Error code is 53 and Error Message is <f:WSManFault xmlns:f="[http://schemas.microsoft.com/wbem/wsman/1/wsmanfault"](http://schemas.microsoft.com/wbem/wsman/1/wsmanfault%22) Code="53" Machine="client-machine"><f:Message>WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer openwec. Verify that the computer exists on the network and that the name provided is spelled correctly. </f:Message></f:WSManFault>.

there are no errors in openwec, both windows 2022 and windows 2025 are deployed in the same subnets and they are part of the domain controller.

we tried running other connections commands and the connection is allowed from windows 2025, any ideas if there are known issues for integrations with windows 2025?

Best Regards!.

Oct 10 '25 20:10 javierdobles

Hi! I'm not aware of any issues with Windows Server 2025 yet but I don't have it set up in my labs. I'll try to reproduce the error asap :)

However, the log message seems to indicate a network or a DNS issue. Do you see any trace of your client in the openwec logs (either access or errors)?

Oct 11 '25 17:10 vruello

no errors or any trace in openwec, regarding this client, in windows 2025, they can resolve the dns with nslookup but when is setup, the error is showing the above

Oct 13 '25 13:10 javierdobles

By implementing a response to http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd requests within OpenWEC, the debugging of scenarios like this would become a bit easier, because OpenWEC would be able to answer to the Test-WSMan powershell tool (includes network connectivity, DNS, authentication checks and better error reporting too).

@vruello Let me know if you find this useful, I'll try to open a PR then.

Oct 13 '25 16:10 MrAnno

no errors or any trace in openwec, regarding this client, in windows 2025, they can resolve the dns with nslookup but when is setup, the error is showing the above

Could you test whether the windows client can communicate with the openwec server? Per example, you can use the Test-NetConnection command.

@MrAnno I didn't know about Test-WSMan. It could indeed be a valuable addition to the project. However, I don't know how much work would be required to implement responses to these requests.

Oct 14 '25 17:10 vruello

I will be adding my outputs as soon as I can.

Best regards!.

Oct 14 '25 17:10 javierdobles

I'll share a sample and stop spamming this issue :) Sorry for the noise.

Sample request and response (click to expand)

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsmid="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">
  <s:Header/>
  <s:Body>
    <wsmid:Identify/>
  </s:Body>
</s:Envelope>

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header/>
  <s:Body>
    <wsmid:IdentifyResponse xmlns:wsmid="http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd">
      <wsmid:ProtocolVersion>http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd</wsmid:ProtocolVersion>
      <wsmid:ProductVendor>OpenWEC</wsmid:ProductVendor>
      <wsmid:ProductVersion>0.3.0</wsmid:ProductVersion>
    </wsmid:IdentifyResponse>
  </s:Body>
</s:Envelope>

Oct 14 '25 19:10 MrAnno

Hello, sorry for the delays, here is my response again:

The forwarder is having a problem communicating with subscription manager at address http://openwec:5985/server. Error code is 5 and Error Message is <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="5" Machine="my-client-host"><f:Message>The WinRM client cannot process the request. The WinRM client tried to use Negotiate authentication mechanism, but the destination computer (open-wec:5985) returned an 'access denied' error. Change the configuration to allow Negotiate authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: Kerberos </f:Message></f:WSManFault>.

Test-NetConnection output:

ComputerName : openwec-host RemoteAddress : my-ip RemotePort : 5985 InterfaceAlias : Local Area Connection SourceAddress : my-client-ip TcpTestSucceeded : True

Oct 15 '25 16:10 javierdobles

Hey, it seems like I came across the same issue. I have seen a bunch of errors in journal like: Authentication failed for 10.137.216.49:53832 (POST:/siemwks): Other(Authorization header does not start with 'Kerberos ') and windows administrators told me they see "negotiation problems" in Eventlog-Forwarding Plugin/Operational. Probably the same as aforementioned. All the clients with errors are Windows 11. Gonna get access, play around and report if i get more information. For now it just a version of OS: 10.0 (26100). P.S. You guys did a great job! I have tried a couple of "enterprise grade" decisions for windows event log collection and openwec is the best so far.

Nov 11 '25 08:11 cdjkee

Hello, some additional information related to the issue: On the client side I have the same "access denied" error code 5, eventid 105. Disabling all the auth protocols except Kerberos on wsman client does not work at all. Actually, disabling Negotiation immediately leads to eventid 105 even though Kerberos is still in the list. The WinRM client cannot process the request. Negotiate authentication is currently disabled in the client configuration. Change the client configuration and try the request again. If this is a request for the local configuration, use one of the enabled authentication mechanisms still enabled. To use Kerberos, specify the local computer name as the remote destination.

With Trace log level on server side all I have got:

2025-11-13T10:15:09.488050542+01:00 DEBUG server - Real client address is 10.14.2.64:59680 2025-11-13T10:15:09.488873515+01:00 DEBUG server::kerberos - Acquired server credentials: Ok(CredInfo { name: HTTP/[email protected], proxy: None, lifetime: 4294967295s, usage: Accept, mechanisms: [GSS_MECH_KRB5] }) 2025-11-13T10:15:09.489605173+01:00 DEBUG server - Received HTTP request from 10.14.2.64:59680: POST /siemtest 2025-11-13T10:15:09.489859962+01:00 WARN server - Authentication failed for 10.14.2.64:59680 (POST:/siemtest): Other(Authorization header does not start with 'Kerberos ')

Nov 13 '25 12:11 cdjkee

Hi! This is an interesting finding. OpenWEC forces the Authorization header to start with "Kerberos ", and it does not seem to work in your case. I wonder whether we should also accept "Negotiate " for newer versions of Windows.

Could you share a network traffic capture on the OpenWEC server (filtering on tcp/5985) so that we can check the HTTP headers provided by the client?

Nov 13 '25 16:11 vruello

Hello, thank you for fast response. Passing full traffic dump will be pretty hard to approve, but the only readable part of it is here:

POST /siemtest HTTP/1.1 Connection: Keep-Alive Content-Type: application/soap+xml;charset=UTF-8 Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAPRlAAAADw== User-Agent: Microsoft WinRM Client Content-Length: 0 Host: is-wec-srv.sec.corp:5985

here is decoded:

Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAPRlAAAADw==\r\n NTLM Secure Service Provider NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_NEGOTIATE (0x00000001) Negotiate Flags: 0xe20882b7, Negotiate 56, Negotiate Key Exchange, Negotiate 128, Negotiate Version, Negotiate Extended Session Security, Negotiate Always Sign, Negotiate NTLM key, Negotiate Lan Manager Key, Negotiate Seal, Negotiate Sign Calling workstation domain: NULL Calling workstation name: NULL Version 10.0 (Build 26100); NTLM Current Revision 15 Major Version: 10 Minor Version: 0 Build Number: 26100 NTLM Current Revision: 15

Nov 14 '25 08:11 cdjkee

Hello! I am also interested in solving this issue. Are there any updates?

Nov 19 '25 10:11 Ghostik2005

Hi! I've added a Windows Server 2025 in my lab.

At first, I had a Kerberos issue (which seems to be the same issue than @javierdobles):

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-WinRM" Guid="{a7975c8f-ac13-49f1-87da-5a984a4ab417}" />
  <EventID>161</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>7</Task>
  <Opcode>0</Opcode>
  <Keywords>0x400000000000000a</Keywords>
  <TimeCreated SystemTime="2025-11-19T18:34:16.9916231Z" />
  <EventRecordID>27</EventRecordID>
  <Correlation ActivityID="{123cb984-5983-0001-babc-3c128359dc01}" />
  <Execution ProcessID="2112" ThreadID="2692" />
  <Channel>Microsoft-Windows-WinRM/Operational</Channel>
  <Computer>SRV-2025.WINDOMAIN.LOCAL</Computer>
  <Security UserID="S-1-5-20" />
  </System>
- <EventData>
  <Data Name="authFailureMessage">WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer wec.windomain.local. Verify that the computer exists on the network and that the name provided is spelled correctly.</Data>
  </EventData>
  </Event>

I realized that the 2025 server was requesting a TGS for the service HOST/wec.windomain.local, but the only SPN configured for my WEC service account was HTTP/wec.windomain.local. After adding the SPN HOST/wec.windomain.local to the WEC service account, the 2025 server successfully retrieved a TGS and began sending events as expected.

Could you try to add the SPN HOST/<WEC> to your WEC service account?

Nov 19 '25 19:11 vruello

Hello, thank you for fast response. Passing full traffic dump will be pretty hard to approve, but the only readable part of it is here:

POST /siemtest HTTP/1.1 Connection: Keep-Alive Content-Type: application/soap+xml;charset=UTF-8 Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAPRlAAAADw== User-Agent: Microsoft WinRM Client Content-Length: 0 Host: is-wec-srv.sec.corp:5985

here is decoded:

Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAPRlAAAADw==\r\n NTLM Secure Service Provider NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_NEGOTIATE (0x00000001) Negotiate Flags: 0xe20882b7, Negotiate 56, Negotiate Key Exchange, Negotiate 128, Negotiate Version, Negotiate Extended Session Security, Negotiate Always Sign, Negotiate NTLM key, Negotiate Lan Manager Key, Negotiate Seal, Negotiate Sign Calling workstation domain: NULL Calling workstation name: NULL Version 10.0 (Build 26100); NTLM Current Revision 15 Major Version: 10 Minor Version: 0 Build Number: 26100 NTLM Current Revision: 15

@cdjkee It looks like your server is trying to perform an NTLM authentication, while OpenWEC only supports Kerberos. Make sure that your WEC AD service account has the SPNs HTTP/<WEC> and HOST/<WEC>.

Nov 19 '25 19:11 vruello

Hi, thank you for your attention. There were no HOST/ record in my setup either, so I got it now as well as a new keytab file. After restart I see some changes, but it all about packet level. Win10 clients still work ok when Win11 clients doesn't. Actually I barely tested it and I'll give a more detailed answer tomorrow, however I can confirm that winrm client now uses SPNEGO and Kerberos with HOST/ SPN. I just realized that I didn't mention a haproxy server which I'm using. Probably it does not affect the situation but I think you have to know. Haproxy as described in openwec docs: tcp, send-proxy-v2 and single backend server.

Nov 20 '25 14:11 cdjkee

Hi, here some logs. Packet sent from the client:

Hypertext Transfer Protocol
    POST /siemtest HTTP/1.1\r\n
        Request Method: POST
        Request URI: /siemtest
        Request Version: HTTP/1.1
    Connection: Keep-Alive\r\n
    Content-Type: application/soap+xml;charset=UTF-8\r\n
    […] Authorization: Negotiate YIIHFwYGKwYBBshortenedAAAACjggTaYYIE1jCCBNKgAwIBBaEIGwZNQ0IuUlWiJDAioAMC
        GSS-API Generic Security Service Application Program Interface
            OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
            Simple Protected Negotiation
                negTokenInit
                    mechTypes: 4 items
                        MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                        MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                        MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX - SPNEGO Extended Negotiation Security Mechanism)
                        MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                    mechToken […]: 608shortenedb1169732d7765632d7372762e6d63622e7275a382
                    krb5_blob […]: 608206cshortened632d7372762e6d63622e7275a382
                        KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                        krb5_tok_id: KRB5_AP_REQ (0x0001)
                        Kerberos
                            ap-req
                                pvno: 5
                                msg-type: krb-ap-req (14)
                                Padding: 0
                                ap-options: 20000000
                                    0... .... = reserved: False
                                    .0.. .... = use-session-key: False
                                    ..1. .... = mutual-required: True
                                ticket
                                    tkt-vno: 5
                                    realm: SEC.CORP
                                    sname
                                        name-type: kRB5-NT-SRV-INST (2)
                                        sname-string: 2 items
                                            SNameString: HOST
                                            SNameString: is-wec-srv.sec.corp
                                    enc-part
                                        etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                        kvno: 4
                                        cipher […]: 591be26ashortened3a92a4d923543870d39a45711496f59b34db677
                                authenticator
                                    etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                    cipher […]: 9785da412shorteneddb728c8f3bcb2c9b8741664d63ac
    User-Agent: Microsoft WinRM Client\r\n
    Content-Length: 0\r\n
        [Content length: 0]
    Host: is-wec-srv.sec.corp:5985\r\n
    \r\n
    [Full request URI: http://is-wec-srv.sec.corp:5985/siemtest]

server side trace log:

2025-11-21T07:17:11.723125757+01:00 DEBUG server - Real client address is 10.14.2.64:61395
2025-11-21T07:17:11.724000990+01:00 DEBUG server::kerberos - Acquired server credentials: Ok(CredInfo { name: HTTP/[email protected], proxy: None, lifetime: 4294967295s, usage: Accept, mechanisms: [GSS_MECH_KRB5] })
2025-11-21T07:17:11.724931271+01:00 DEBUG server - Received HTTP request from 10.14.2.64:61395: POST /siemtest
2025-11-21T07:17:11.725127481+01:00 WARN server - Authentication failed for 10.14.2.64:61395 (POST:/siemtest): Other(Authorization header does not start with 'Kerberos ')

New keytab content:

KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   4 01.01.1970 01:00:00 HTTP/[email protected] (aes256-cts-hmac-sha1-96)
   4 01.01.1970 01:00:00 HOST/[email protected] (aes256-cts-hmac-sha1-96)

Nov 21 '25 11:11 cdjkee

Hi @cdjkee! Thanks for all those details. I don't know why your server is using Negotiate rather than Kerberos authentication method.

Could you check if the Kerberos auth method is enabled for the WinRM client?
Could you share the output of the following command: winrm get winrm/config/client?

According to the MS doc (https://learn.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections), Kerberos is used by default when both source and destination computers are domain joined, which should be the case here.

I tried to disable Kerberos auth method to force my 2025 server to use Negotiate, but I couldn't make it work. I get the following error messages in the EventLog-Forwarding channel:

The WinRM client cannot process the request. Kerberos authentication is currently disabled in the client configuration. Change the client configuration and try the request again

I've created a branch to support Negotiate auth method: https://github.com/vruello/openwec/tree/auth_negotiate. I could not test it, but maybe you could try it?

Nov 21 '25 20:11 vruello

Hey, @vruello! You did an amazing job. It seems like I finally found the source of a problem. At first, you were absolutely right about HOST/ SPN. This was necessary. At second, playing around WinRM client settings I never touched "Trusted Hosts = *" coz why would I? But this matters. Cleaning up all the mess I made trying to enable and disable different options of a client, to send you a clean report, I deleted all the registry records in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client and it worked! And it broke back right after gpupdate. I found the only value in client settings coming with GPO was bloody "Trusted Hosts = " (Actually in registry there are two of them, one TrustedHosts=1 and second TrustedHostsList=) Faulty winrm get winrm/config/client:

Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = false
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = * [Source="GPO"]
    spn_prefix = HOST

And the OK one:

Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = false
    Auth
        Basic = true
        Digest = false
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts
    spn_prefix = HOST

In addition: this spn_prefix = HOST is unique for win11 machines. Neither WinSrv2016 nor Windows 10 clients have this parameter set. Seems like this is the reason why HOST/ SPN is necessary with Win11 clients and HTTP/ is fine enough with Win10.

I have already sent your auth_negotiate binaries, and taking into account the bureaucracy in changing the parameters of the GPO I will have time to test at least during the week.

Thank you very much for help!

Nov 22 '25 14:11 cdjkee

Hey! I'm glad it's working for you now :-)

I could reproduce the behavior by configuring TrustedHosts=*, nice catch! So my patch did not work, but I fixed it and now OpenWEC supports the SPNEGO authentication method (see #307).

In addition: this spn_prefix = HOST is unique for win11 machines. Neither WinSrv2016 nor Windows 10 clients have this parameter set. Seems like this is the reason why HOST/ SPN is necessary with Win11 clients and HTTP/ is fine enough with Win10.

Absolutely! I added this SPN to the documentation (see #307).

I'll close this once #307 is merged.

Nov 22 '25 19:11 vruello