EAP-TLS Wireless

Question

I have one SSID with EAP-TLS with certificate based authentication. If the endpoint have valid certificate then the client can connect to the network. But if the client not have certificate i want this endpoint will get access to the guest vlan (only can access to the internet). I already configure on the WLC side where if authenticate failed then will get vlan guest by default.

From endpoint side when the endpoint not have certificate then there are a prompt to enter the username and password, most likely the client not send eap-tls. Can we change this behaviour from windows endpoint side so even the client not have certificate the endpoint not aksed to enter the username password?

Answer 1

Hi Handian Sudianto,

The behavior you are observing happens because the Windows native supplicant encounters an 802.1X network without a strictly defined local profile, causing it to fall back to prompting the user for credentials to attempt alternative methods like PEAP. To resolve this, you must push a strictly defined Wireless Network Profile to the endpoints using Group Policy or Microsoft Intune.

You can generate the required configuration by configuring a test machine specifically for EAP-TLS authentication on that SSID and using the command prompt utility to run the command netsh wlan export profile name="poc-nac" folder=C:. You then deploy this resulting XML file across your enterprise environment, ensuring the EAP configuration section is locked exclusively to certificate-based authentication. This removes the operating system's ability to prompt the user for an alternative username and password.

Once this profile is deployed, machines lacking the valid client certificate will fail the 802.1X exchange silently and immediately at the OS level, allowing your network infrastructure to handle the fallback routing seamlessly. You can verify this silent rejection behavior by checking the Microsoft-Windows-WLAN-AutoConfig/Operational log within the Windows Event Viewer, specifically looking for Event ID 11006 or 12013, which will indicate the precise authentication failure reason without any user interaction.

Hope this answer brought you some useful information.

Domic V.

Answer 2

Hi Handian Sudianto,

Has your issue been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

Domic V.

Answer 3

Handian Sudianto Hi, unfortunately, it's technically impossible to suppress the native Windows credential prompt on a machine you don't manage. The default behavior of the Windows Native 802.1X Supplicant is to request credentials to attempt fallback protocols like PEAP whenever it encounters an enterprise network without a locally defined profile. Because you lack the administrative privilege to inject an explicit EAP-TLS XML profile onto these guest endpoints, the operating system will always trigger that prompt for the user.

Relying on an 802.1X authentication failure to drop unmanaged devices into a guest VLAN is an architectural anti-pattern that inherently causes a confusing user experience due to these unavoidable OS-level prompts. To achieve a seamless guest onboarding experience, standard enterprise network design dictates separating these access methods. You will need to provision a dedicated Open SSID leveraging Web Authentication via a Captive Portal, or an Opportunistic Wireless Encryption SSID, specifically mapped to your guest VLAN. This completely bypasses the 802.1X supplicant on the unmanaged device, eliminating the credential prompt while still fulfilling your security and isolation requirements.

Domic V.

Answer 4

Windows wireless clients behave according to the 802.1X/EAP method configured in the WLAN profile. When the profile is set to use EAP‑TLS but no suitable client certificate is found, Windows falls back to prompting for user name and password (for another EAP method) instead of silently failing.

To achieve the behavior where:

• Devices that have a valid client certificate connect to the secure VLAN, and
• Devices without a certificate fail 802.1X so the WLC can place them in the guest VLAN,

the Windows profile must be configured so that it uses only certificate‑based authentication and does not allow password‑based methods.

Key points from the EAP‑TLS/PEAP‑TLS requirements:

• With EAP‑TLS or PEAP‑TLS, the client authenticates only with certificates that meet the minimum client certificate requirements (issued by an enterprise CA or mapped in AD DS, chains to a trusted root, has the Client Authentication EKU, and valid SubjectAltName, etc.).
• Wireless clients display only certificates that contain the Client Authentication purpose and are not password‑protected or smart‑card/registry‑based.

On the Windows client, configure the WLAN profile so that:

1. The network authentication method is EAP‑TLS (or PEAP‑TLS with “Smart Card or other certificate”) only.
2. No additional EAP methods (such as PEAP‑MS‑CHAP v2) are enabled or offered as fallbacks.
3. The profile is deployed (for example via Group Policy or MDM) with those constraints so users cannot change it.

With such a profile, if the client does not have a valid certificate that meets the EAP‑TLS requirements, 802.1X authentication fails instead of prompting for credentials. The WLC can then apply its “authentication failed → guest VLAN” policy as designed.

If authentication still does not fail as expected, review the WLAN AutoConfig operational log on the client (Event Viewer → Applications and Services Logs → Microsoft → Windows → WLAN‑AutoConfig/Operational) to confirm the EAP method in use and the certificate selection/validation result.

---

References:

• Configure Certificate Templates for PEAP and EAP requirements
• Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS
• Advanced troubleshooting 802.1X authentication
• Deploy Password-Based 802.1X Authenticated Wireless Access
• WPA2-Enterprise with TLS profile sample
• WPA-Enterprise with TLS profile sample
• WPA3-Enterprise 192-bit mode with EAP-TLS profile sample