[EXT] Re: Freeradius vs Security
Alberto Martínez Setién
alberto.martinez at deusto.es
Wed Apr 3 16:52:40 CEST 2019
When I looked at doing this several years ago, I found it could really
> confuse the
> client supplicants and force users to turn their WiFi off and on to
> Have you not found the same?
Until now checks always end in either the device refusing to continue the
EAP exchange (eg.: Windows 10, Apple devices), the device continuing only
to fail establishing (Access-Reject) the TLS tunnel (eg.: Android), or the
device really establishing the TLS tunnel and then sending authentication
material, which we answer with an Access-Reject.
>From our experience, supplicants always retry authentication just after an
Access-Reject, even if they didn't trust the server cert! The exception is
the native Windows 7 supplicant, that interprets an Access-Reject as a
credentials error, does not retry even once and prompts for a new user/pass.
With FreeRADIUS 3.0.18 we will be able to do-not-respond on the Post-Auth
Reject block if the check is ongoing. This should solve the Windows 7 issue
and overall be a more elegant behaviour for devices like Android.
More information about the Freeradius-Users