[RADIATOR] Ideas on Radiator setup with OpenLDAP and Kerberos serving Windows and Ubuntu Clients

[Nicola Volpini]

Hi everyone!

I just entered the world of RADIUS and I'm a bit confused...
We're currently experimenting with Radiator and we're very impressed by
its capabilities.

We have a fairly complex setup which involves Ubuntu 12.04/10.04 and
Windows 7 clients, OpenLDAP with SASL, Heimdal Kerberos and Cisco
Catalyst 2960 Switches.
Our Idea is to use either PEAP/MSCHAPv2 for ease of deployment or
EAP-TLS, both providing the cross platform compatibility we aim for.
After the authentication the user would be mapped to the right vlan by
the switch depending on her/his "gid" value obtained via an LDAP query
(which is probably the easy part!).

>From what I understood the choice between PEAP and EAP-TLS is mainly
dependent on the compatibility with our current user/password store. If
I got it correctly, it's mandatory to have passwords stored in cleartext
to allow PEAP/MSCHAPv2 to work, which is not our case since we hash the
passwords. Authenticating to Kerberos is also apparently not possible
because we're not using digest!
Even if this setup worked I assume we would still need the user to
reconfigure the supplicant every 90 days (we enforce a password change)
which is kinda annoying for them.

At this point EAP-TLS would be the way to go! A question arises tough:
are the EAP-TLS certs generated specifically for the user or for the
machine? The former would be preferred since we could then extract the
username and proceed with an LDAP query, subsequently obtaining the
aforementioned "gid" value to map the right switch port... but then, how
would the user be provided her/his first cert on linux when logging in
for the first time? Argh... this is not really a Radiator issue, I know :)

As you can read I'm pretty confused, I'm therefore open to suggestions
on how to tackle the challenge! Anyone with a similar setup?

Thanks for your help!
Nicola

-- 
Nicola Volpini
Infrastructure Operations
The information in this email is confidential and may be legally privileged.
If you are not the intended recipient, you must not read, use or disseminate that information
and upon reception, permanently delete the original and destroy any copies.
Although this email and any attachments are believed to be free of any virus
or any other defect which might affect any computer or IT system into which
they are received and opened, it is the responsibility of the recipient to
ensure that they are virus free and no responsibility is accepted by Kambi
for any loss or damage arising in any way from receipt or use thereof.