Azure App Gateway / WEC for Entra Joined endpoints

Hi @ Hardwick, Lewis,

Welcome to Microsoft Q&A Platform

It sounds like you’re trying to move your Windows Event Forwarding (WEF/WEC) setup from Kerberos-based auth on domain-joined machines to certificate-based auth over HTTPS on pure Entra-joined devices and you’d like to front it all with Azure Application Gateway.

Configure your WEC collector for certificate-based WinRM

• On the collector server, create an HTTPS WinRM listener on 5986 that requires client certificates.
• Install a server TLS cert (from your PKI or Key Vault).
• Issue client certificates (usually via Intune SCEP/PKCS or on-prem PKI).

Set up your WEF subscriptions to use HTTPS

• In your subscriptions (Source-initiated), point the subscription URL to https://:5986/wsman.
• In the subscription XML, set the transport to “HTTPS” and client authentication to “Certificate.”

Deal with certificate distribution •

• Use Intune to push the client certs + private keys to your Entra-joined devices, or integrate with your corporate PKI via SCEP.
• Make sure the collector’s root CA is trusted on the clients.

Front the collector with Application Gateway

• App GW can terminate TLS or do end-to-end TLS, but it does not support mutual-TLS (mTLS) client cert auth. It can only present one server cert to the client and one to the back end.
• If your collector expects a client cert for auth, App GW will strip it unless you put a proxy behind it that can re-inject the cert.

Workarounds :

• Skip App GW for the mTLS endpoint—expose the collector directly (for example via Azure AD Application Proxy, which does support mTLS for WinRM).
• Put an NGINX or Azure Kubernetes Nginx Ingress (with mTLS support) behind App GW. App GW will do TLS offload or pass-through, and your nginx handles the client cert authentication.

Please "upvote" if the information helped you. This will help us and others in the community as well.

Hello Hardwick, Lewis

We understand you are planning to move from domain-joined endpoints using Kerberos authentication for Windows Event Collection (WEC/WEF) to Entra ID–joined devices. In these cases, since Kerberos is not available, the recommended method is certificate-based authentication over HTTPS. This ensures secure communication between event forwarders and the collector through mutual TLS, where both sides use certificates to verify each other.

Typically, the WEC collector is set up with an HTTPS WinRM listener, and client certificates are distributed to endpoints, often via Intune using SCEP or PKCS. Event forwarding subscriptions are updated to use HTTPS with certificate-based authentication, which works well for Entra-only environments and supports devices connecting over the internet or external networks. 

If you are considering Azure Application Gateway in front of the WEC service, note that while it supports TLS termination and mutual TLS at the gateway, it does not pass the client certificate to the backend as required by WEC. This can cause authentication issues.

Because of this, most setups either expose the WEC endpoint directly using secure network controls like firewalls or VPN, or use an intermediate proxy that correctly handles client certificates. Direct HTTPS exposure of the collector with proper network and certificate controls is generally the simpler and more reliable option.

In summary, moving to certificate-based authentication over HTTPS for Entra-joined devices is a recommended practice, but using Azure Application Gateway directly with WEC collector is not advised due to client certificate handling limitations.

Please do not forget to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.