Windows Event Forwading / HTTPS - Selecting Client Certificate

Question

Hello all.

I've followed instructions to set up windows event forwarding to a remote collector using HTTPS (since the collector is a non-domain machine). Everything seems to work great, except in the case where the forwarder (client) has an existing client certificate in the certificate store that is also allowed to be used for client authentication (seems even if it is not named using the machine's FQDN). For instance -- if I have a Certificate Authority installed on the machine and the CA certificate is in the certificate store, and it's marked as available for all purposes, the client certificate I generated specifically for use for the WinRM / WEF setup doesn't necessarily get used to authenticate to the remote WEC. Is there a way to configure a thumbprint of the certificate that should be used in this case?

Thanks in advance.

Kendal

Answer 1

Hey Guys, I am trying to forward on-premise Domain Controller logs to an AWS Collector server, the URL is the Elastic Load Balancer fixed DNS alias and the SSL encryption is terminated at the ELB layer so when it hits the Windows EC2 instance, it should be communicating on 5985. On-prem servers > Elastic Load Balancer:5986 > SSL Terminates to Windows EC2 Instance: 5985. We have a server/client auth cert installed on the ELB that is from the same Intermediate CA Issuing server as the server/client certs on our Domain Controllers. I've seen documents that say you need to include a thumbprint in the https://URL:5986/wsman/subscriptionmanager URL - can anyone confirm which cert Thumbprint needs to be used, the Issuing CA server or just the cert thumprint thats installed on the ELB?

Answer 2

That's the same behavior on my servers : some choose the good certificate and some other don't.

Thank you for your answer anyway!
I'll write here if I'll find a solution on my side.

Answer 3

Franois,

I have not found a solution for this yet. I have a few servers that it "just works" on which seem to be an anomoly, but in my test environment it fails 100% of the time. I'm still waiting for any sort of solution / answer from microsoft.

Answer 4

Hi -- I just saw your responses.

I am certain that I have the root and intermediate CA certificates installed on the machines on both sides (the event forwarder and the event collector), as I can successfully authenticate and logs are forwarded if I don't have other "client authentication" certificates also installed on the event forwarders. Here is the scenario -- I have event forwarders that are part of a domain, and as such, they might have certificates with "Client Authentication" purpose installed on them from an enterprise CA for other purposes already. Now, I want to also forward logs from these servers to an event collector that is not on the domain (in fact, it's provisioned off-network in a cloud provider network that's isolated from most everything else). I configure a new standalone CA and sign certificates for both the event collector and the windows event forwarders and configure the intermediate and root CAs in the trust store, as well as installing the signed certificates (one with Server Authentication on the WEC where the CN matches it's FQDN and one with Client Authentication on the WEF where the CN matches it's FQDN). Using a command similar to:

winrm g winrm/config -r:https://<WEC_HOSTNAME>:5986 -a:certificate -certificate:"<Thumbprint of the client authentication certificate from the WEF>"

... I successfully get the winrm configuration from the WEC. So I know authentication and communication can happen when the correct client authentication certificate is manually specified. However, when the WEF is configured via group policy to configure the forwarding, even though the configuration seems to include the IssuerCA= argument, it seems that in some cases (maybe based on the order in which the certificates are returned from some query internally), the wrong "Client Authentication" certificate is used to try and authenticate to the WEC. I don't have the logs in front of me, but I'm pretty sure that from the WEC when I looked at the CAPI2 operational logs and the WinRM operational logs, I saw the wrong client certificate being used to try and authenticate, and the authentication failed. I had assumed that somehow that by configuring that IssuerCA= argument in the subscription manager configuration in the group policy, that it would limit the client certificates that are available for use in authenticating to the WEC to those signed by that CA -- but that doesn't appear to be the case. Let me know if it's useful and I'll try to replicate the problem once again and pull those operational logs from the WEC.

Thanks for checking back.

Kendal.

Answer 5

Hi,
As described in the guidance of setting up source initiated WEF with different domains, if the client certificate has been issued by a different Certification Authority than the one of the Event Collector then those Root and Intermediate certificates needs to be installed on the Event Collector as well.

Certificates requirements
https://learn.microsoft.com/en-us/windows/win32/wec/setting-up-a-source-initiated-subscription#certificates-requirements

Per searching the internet, here are more references regarding the certificates used in WEF.
Functional Kerberos for all endpoints (domain) or a valid TLS certificate (non-domain) for the Event Log Collector servers.
The signing CA of the server certificate must be trusted by the forwarder computers​.

https://support.logbinder.com/SuperchargerKB/50221/Using-HTTPS-with-Windows-Event-Forwarding-and-Supercharger
https://itworldjd.wordpress.com/2017/08/05/how-to-configure-event-forwarding/

Please note: Information posted in the given link is hosted by a third party. Microsoft does not guarantee the accuracy and effectiveness of information.

----------

Hope this helps and please help to accept as Answer if the response is useful.

Thanks,
Jenny