Banning users in a nice way...

Stefan Winter stefan.winter at restena.lu
Wed Jun 27 13:17:15 CEST 2007


> What we really want to be able to do, is for users with broken software,
> force the wireless association to succeed, and put them on the
> unauthorised VLAN. Of course just sending a plain old Access-Accept
> packet isn't sufficient, as it requires the tunneled authentication to
> succeed as well...
>
> Has anyone got any ideas ?
>
> I'm assuming theres no way to do it..
>
> Oh and by broken I mean windows XP type broken, as in will only attempt

 1) TLS authentication broken... 
 2) and sends the username and password a user logged into the machine with by 
default broken...

Hmm. You can always catch XPs with the bad machine user name (your second 
case) because they will have no @suffix (we're talking eduroam here, I 
guess?). If you only use the "suffix" realm seperator, ordinary 
badly-configured users of the form <windows-login-uname> or 
<DOMAIN/windows-login-uname> will be caught by realm NULL in proxy conf. You 
can then define realm NULL to be auth'd LOCAL and accept all their requests 
(don't check user cert on your server, and for TTLS/PEAP force Auth-Type in 
inner request to Accept) and add reply items with your quarantine VLAN - 
assuming that your WLAN at least can assign VLANs dynamically.

For your case 1): depends. If there actually is a user cert on the client's 
box and its CN does not contain an @, same as above applies. If their CN does 
contain an @, well, then you are pretty much lost. Shouldn't be many though.

Not exactly trivial I guess. Would make a good example in the Roaming Cookbook 
if you manage to get it running :-)

Greetings,

Stefan

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: stefan.winter at restena.lu     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070627/7e5dbaba/attachment.pgp>


More information about the Freeradius-Users mailing list