If you have setup your Cloud RADIUS instance and are having trouble authenticating users, this guide will help you troubleshoot your Cloud RADIUS configuration for EAP-TLS or Entra ID Wifi Authentication in EZRADIUS.
In EAP-TLS authentication, the client sends a certificate to the RADIUS server. The RADIUS server validates the certificate and if it is valid, it sends an Access-Accept message to the client. If the certificate is invalid, the RADIUS server sends an Access-Reject message to the client. There are many issues that might be causing the EAP-TLS authentication to fail. Here are some common issues and how to troubleshoot them:
Most of them start with the same error message so it is important to read the error message carefully to understand the root cause of the issue.
If you see an error “Failed to build and validate certificate (XXX): UntrustedRoot: self-signed certificate in certificate chain” or “Invalid certificate: Failed to build certificate chain to a valid CA” it means that the certificate is not trusted. Please ensure that the certificate is part of your Policy Trusted Certificate Authorities.
If you see an error “Exception occurred when validating the CRL” it means that the Certificate Revocation List (CRL) was not accessible by EZRADIUS. Please ensure that the certificates you are using have a valid CRL accessible through http (this is for the full chain, so it might also be the Root CA CRL).
This error usually occurs when the client and the server cannot agree on the cryptographic tunnel to start the authentication. The most common issue with this is the client not trusting the server certificate. For this you must ensure that the server certificate is trusted by the client (if testing manually just accept when it as).
When using an MDM you must distribute the Root Certificate Authority, (found under “Server Certificate in your RADIUS Policy) to your devices. and Add the subject name and IP address of the RADIUS server to the wifi profile.
The other issue is if the client does not support the cryptographic tunnel that the server is trying to use. In this case, we recommend looking at the device logs to see what is the issue.
For this you must ensure that the server certificate is trusted by the client (if testing manually just accept when it as).
When using an MDM you must distribute the Root Certificate Authority, (found under “Server Certificate in your RADIUS Policy) to your devices. and Add the subject name and IP address of the RADIUS server to the wifi profile.
“EAP Session was lost” is a common issue when troubleshooting RADIUS, it usually means that the client device did not respond to the RADIUS server in time. This can be caused due to many reasons, here are the most common ones:
If your device (laptop, phone, etc) has the timeout set too low, it might timeout before the RADIUS server responds. causing it to stop responding to the RADIUS server. To troubleshoot this increase the timeout on your device, if you are using and MDM such as Intune, then you can increase the timeout in the wifi profile (EZRADIUS times out after 30 seconds, so we recommend setting it to 30 seconds).:
By default most networking devices have the RADIUS timeout set to 5 seconds, if the RADIUS server does not respond in 5 seconds the networking device will stop responding to the RADIUS server, this does not account for RADIUS servers not hosted in your network, so we recommend increasing the timeout to 30 seconds. Here is a sample on how to setup the RADIUS timeout under RADIUS Advanced Settings a Cisco Meraki device:
We have seen some networking devices (mostly cisco (including Meraki) and fortinet) that have issues when there are multiple IP addresses in the RADIUS (They will send the request to the first IP address and then the second IP address, but the second IP address will not respond since the first IP is the one that started the authentication). If you are facing this issue, we recommend removing the second IP address from the RADIUS configuration (Don’t worry while it is only one IP address that does not mean it is one server we have multiple servers per availability zone).
When there are no logs or the logs are ambiguous such as “EAP session lost”, it is usually due to the RADIUS server not receiving the request. This can be caused due to many reasons, some of them are network related, but some others can be caused by the Windows device not trusting the RADIUS server certificate or the network to see these logs in Windows you must:
If you are using Fortinet devices, and you updated to Fortigate 7.2.10 you are probably getting the ‘Invalid secret for the server’ error.
This is due to the Fortigate now requiring the Message Authenticator attribute in the RADIUS request (while not sending it in the initial request). To fix this you must enable the “Always Send Message Authenticator” in your RADIUS policy in EZRADIUS.
If you see the error “No matching access policies” it means that we couldn’t find any access policies that match your requirements this can be caused due to two reasons: