WEC in an Non-AD / Entra-Joined Windows 11 Environment
If either the collector or forwarder is not an AD domain member, or if they are not part of the same AD trust scope (forests and external trusts), WEC cannot use Kerberos to authenticate between collector and forwarder.
Entra-joined Windows 11+ PCs are a growing example of this type of environment.
When Kerberos is unavailable, the alternative is certificate-based authentication over HTTPS. While certificates require more effort, one important advantage of certificate-based WEC over HTTPS is that you can forward events over the Internet so that you still have near real-time log collection from users travelling, working from home or at business partners.
First, we will go over the basic requirements of implementing WEC using certificates. Then we will focus on the increasingly common scenario
of Entra-joined Windows 11+ forwarders
managed by Intune including SCEP (Simple Certificate Enrollment Protocol) based deployment of client certificates.
We will avoid repeating general WEC configuration steps already covered in WEC in an Active Directory Environment.
Planning
Both collectors and forwarders require a unique certificate and private key tied to their FQDN. Collectors require a server certificate just like a web server. Forwarders require a client certificate.
Which CA will you use for issuing server certificates to collectors? Which CA will you use for issuing client certificates to forwarders? All computers must trust the root certificate authorities that ultimately vouch for the client and server certificates. And the CAs must be network accessible to both collector and forwarder for revocation checking. This is particularly important to keep in mind when supporting WEC over the Internet.
Of course, your collectors must be reachable by your forwarding devices. Will your forwarders always be on your internal network, always on the Internet or split their time between both? Forwarders need to be able to resolve the DNS name of each collector, from each location where the device needs to send events.
What TCP
port will you use for the HTTPS communication between collector and forwarder? For HTTPS, WinRM defaults to using 5986 but if you are forwarding events from computers on the Internet, you should consider using 443 instead to ensure it is not blocked by ISP and other firewalls. Any firewalls between the forwarder and collector will need to permit TCP connections to the port you select on your Collectors to host WEC (defaults to 5986 but you may decide to use 443 if forwarding events from over the Internet).
Collector Configuration
Make sure the root CA of the CA that will be issuing client certificates to forwarders is in the collector’s Trusted Root CAs store.
Enroll the collector with a server certificate where its Subject or SAN properly specifies its FQDN. The certificate’s allowed purposes need to include server authentication.
Next, since WinRM runs as NETWORK SERVICE, grant the NETWORK SERVICE Read access to the private key of the server certificate.
You need to create a WinRM
listener for that port, protocol, DNS name and certificate.
Next create a subscription where you specify
Create a local unprivileged account on the collector without any permissions or group memberships. This is a “dummy” account that WinRM will impersonate when clients connect via client certificate.
Finally, link the client certificate issuing CA and the local account with a
winrm certificate mapping.
Forwarder Configuration
Make sure the forwarder has the root CA of the collector’s server certificate in its local Trusted Root CAs store.
Enroll each forwarder with a certificate from the same issuing CA as specified above. Make sure the certificate’s subject specifies the FQDN of the forwarder as discussed under
Allowed Forwarders. The certificate’s allowed purposes need to include client authentication.
Next, since winrm runs as NETWORK SERVICE, grant the NETWORK SERVICE Read access to the private key of the client certificate.
Finally, configure the
target subscription manager entry on the forwarder to access the collector via HTTPS using its FQDN and port number as defined on the HTTPS listener. Include the Issuer CA= parameter specifying the thumbprint of the issuing (not root) CA of the client certificate.
For detailed treatment of forwarding events from Entra-joined PCs see
Managing Entra-joined Forwarders via Intune and Microsoft Cloud PKI. But first let’s recap how events will flow via certificate-based WEC.
Event Flow
The collector is listening for connections from forwarders on the port specified in the WinRM listener for incoming HTTPS specifying its FQDN. The collector answers such connections by authenticating itself using the server certificate specified on the WinRM listener.
The forwarder verifies the collector’s certificate chain including online revocation checks.
The forwarder authenticates itself by looking in its local certificate store for a certificate signed by the CA specified in the target subscription manager string where its local computer name FQDN matches the certificate’s subject.
The collector verifies the forwarder’s certificate chain including online revocation checks.
The collector next determines if there is a certificate mapping linking the issuing CA of the forwarder’s certificate to a local account.
Finally, the server returns any subscriptions where the forwarder’s FQDN matches AllowedSubjects, does not match DeniedSubjects and where the forwarder’s certificate’s issuing CA matches AllowedIssuerCAs.
The forwarder subscribes and begins sending matching events.
Managing Entra-joined Forwarders via Intune and Microsoft Cloud PKI
To forward events from Entra-joined Windows devices you’ll need to use Intune in place of Group Policy and provision the forwarders with certificates via a CA that supports SCEP. We will use Microsoft Cloud PKI in this example.
In Intune \ Tenant Administration \ Cloud PKI setup your root CA and issuing CA.
Download the root CA’s certificate in a .CER file. Install the certificate in the Collector’s Trusted Root CAs store.
Next, create policies in Intune that configure your Entra-joined Windows 11+ devices to
- Trust your root CA
- Request a client certificate via SCEP from your Issuing CA
- Use your collector’s target subscription manager string
- Configure the computer’s primary DNS suffix to match the DNS name in the forwarder’s certificate
- Configure other WEC related settings
Create the following configuration policies in Intune and assign them to the Entra-joined Windows devices that will be forwarding events.
Trusted Certificate
Trust the Root CA of the Client Certificate Issuer
Your Windows event forwarders need to trust the root CA of the CA that will issue their client certificates. Use the Trusted Certificate template to add the Root CA's certificate to the Trusted Root CAs certificate store on the Windows devices.
If you are using Microsoft Cloud PKI, you can download the Root CA's certificate from Intune \ Tenant Administration\ Cloud PKI. Select the ROOT CA and then click Properties.
Note: this should be the ROOT CA - not an intermediate or issuing CA.
Trust the Root CA of the Collectors’ Server Certificate Issuer
Is the Root CA for your collectors' server certificates different than the above CA? If so, add another policy so that your Windows forwarding devices will trust the server certificates of your Windows Event Collectors.
(if there are any Managed Issuing CA for server certificates, list their CertificateAuthority.Issuer)
SCEP Certificate
Use the SCEP Certificate template to configure Windows devices to request a client certificate from your PKI.
Subject name format: CN={{DeviceName}}.yourdomain.com where "yourdomain.com" matches the domain name suffix you configured on the DNS tab on this Entra Tenant here in Supercharger.
Configure remaining settings similar to:
Settings Catalog
Windows Components > Event Log Service > Security
Maximum Log Size (KB): 204800
Configure log access: Enabled
Log Access (Device): O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)
Control Event Log behavior when the log file reaches its maximum size: Disabled
Specify the maximum log file size (KB): Enabled
Windows Components > Event Forwarding
SubscriptionManagers (Device): Server=HTTPS://wec1.montereytechgroup.com:5986/wsman/SubscriptionManager/WEC,Refresh=300,IssuerCA=ea7265ce28f2731e896488066a8dd6589887fe9a
Configure target Subscription Manager: Enabled
Network > DNS Client
Enter a primary DNS suffix: (Device): clients.montereytechgroup.com
Primary DNS suffix: Enabled
Remediation and Detection Scripts
Finally, configure remediation scripts to address certain settings for which there are no existing pre-built Intune configuration policies:
- Set the WinRM service to automatically start
- Grant NETWORK SERVICE Read access to the client certificate
Manage, Scale and Heal Windows Event Collection with Supercharger
Download •
Enterprise Pricing •
Ask Sales