Banning users in a nice way...
Hi, Being a nice friendly openish institution, and not wanting to overload our helpdesk staff with hundreds of users trying to set up their laptops, we decided to make registration, a self service kind of affair. We decided to setup an unauthorised VLAN, on this VLAN there exists a support server , serving support pages. On wired connections, assigning users to this VLAN is fine .. our HP Procurve switches have a lovely feature called OpenVLAN which assigns users with broken supplicant software to an arbitrary VLAN. Unfortunately there is no such solution for the wireless access points.. *sigh*.. So we currently have to reject broken supplicants, failed authentication attempts etc ... Our solution to this is not as smooth as I would like ... and that is to create a second unauthenticated, unencrypted BSSID which is attached to our unauthorised VLAN. Users connect to this BSSID, register, setup their software, then connect to the 802.1x authenticated BSSID. 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 TLS authentication broken... and sends the username and password a user logged into the machine with by default broken... and so can never work out of the box broken. Theres no issues with Mac Users, everything works fine there. and were assuming people running linux are clever enough to setup x supplicant without support :) -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
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@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
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.
No certs on users boxes, completely vanilla installs... Well as vanilla as a students laptop can be ... vanilla + Azureus + Kazza + Spyware
Not that I can think of. You shouldn't be able to coax a supplicant >onto a network by munging authentication (this is a *good* thing). josh.
Yes it is I suppose :) This is what I suspected... I was planning on just sending an Access-Accept EAP packet and seeing what happened. But i'm guessing even if it did work (due to microsoft supplicant being horribly broken) it would go against quite a few RFCs, and wouldn't really make a good case study for JRS ;) Thanks for both your replys :) -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Hi,
Oh and by broken I mean windows XP type broken, as in will only attempt TLS authentication broken... and sends the username and password a user logged into the machine with by default broken... and so can never work out of the box broken.
FWIW, an unconfigured Windows XP box will not send anything on EAP-TLS for either wired or wireless either - as it needs to have a private certificate or smartcard. both of which are absent. only if you do a quick change of that default entry to make it PEAP will the next broken bits appear (use windows login/password for authentication etc) no. the only sane way is to provide an open wifi connection which is a walled garden under which they can read onfig docs or install a nice configurator program to set their wifi up properly
and were assuming people running linux are clever enough to setup x supplicant without support :)
if they can get their wifi drivers compiled and running, configuring wpa_supplicant is easy! PS dont forget folks that wpa_supplicant also works on the wired interfaces on linux too....so dot1x on wired is 'trivial' with linux alan
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Stefan Winter