Setting up RADIUS + LDAP for WPA2 on Ubuntu

Question

I'm setting up a wireless network for ~150 users. In short, I'm looking for a guide to set RADIUS server to authenticate WPA2 against a LDAP. On Ubuntu.

• I got a working LDAP, but as it is not in production use, it can very easily be adapted to whatever changes this project may require.
• I've been looking at FreeRADIUS, but any RADIUS server will do.
• We got a separate physical network just for WiFi, so not too many worries about security on that front.
• Our AP's are HP's low end enterprise stuff - they seem to support whatever you can think of.
• All Ubuntu Server, baby!

And the bad news:

• I now somebody less knowledgeable than me will eventually take over administration, so the setup has to be as "trivial" as possible.
• So far, our setup is based only on software from the Ubuntu repositories, with exception of our LDAP administration web application and a few small special scripts. So no "fetch package X, untar, ./configure"-things if avoidable.

UPDATE 2009-08-18:

While I found several useful resources, there is one serious obstacle:

Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.

Basically the Ubuntu version of FreeRADIUS does not support SSL (bug 183840), which makes all the secure EAP-types useless. Bummer.

But some useful documentation for anybody interested:

• http://vuksan.com/linux/dot1x/802-1x-LDAP.html
• http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius

UPDATE 2009-08-19:

I ended up compiling my own FreeRADIUS package yesterday evening - there's a really good recipe at http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (See the comments to the post for updated instructions).

I got a certificate from http://CACert.org (you should probably get a "real" cert if possible)

Then I followed the instructions at http://vuksan.com/linux/dot1x/802-1x-LDAP.html. This links to http://tldp.org/HOWTO/html_single/8021X-HOWTO/, which is a very worthwhile read if you want to know how WiFi security works.

UPDATE 2009-08-27:

After following the above guide, I've managed to get FreeRADIUS to talk to LDAP:

I've created a test user in LDAP, with the password mr2Yx36M - this gives an LDAP entry roughly of:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

When using radtest, I can connect fine:

> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
    User-Name = "msiebuhr"
    User-Password = "mr2Yx36N"
    NAS-IP-Address = 127.0.1.1
    NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
> 

But when I try through the AP, it doesn't fly - while it does confirm that it figures out the NT and LM passwords:

...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP.  Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...

It is clear that the NT and LM passwords differ from the above, yet the message [ldap] user testuser authorized to use remote access - and the user is later rejected...

Answer 1

I'll try to answer the LDAP question here.

Here's the short answer: make sure the ldap module is removed from the authenticate section, and make sure the mschap module is present in both the authorize and the authenticate section. And just ignore the 'No "known good" password'.

And now here's the (very) long answer.

How does the ldap module work?

When you activate the ldap module in the authorize section, this is what it does when a RADIUS packet is received by FreeRADIUS:

1. it tries to bind to the LDAP server (as a guest user, or using the given identity if one is configured in ldap.conf)
2. it searches for the user's DN entry using the filter under the base DN (configured in ldap.conf).
3. it fetches all the LDAP attributes it can get among those configured in ldap.attrmap, and converts them into RADIUS Attributes.
4. it adds those attributes to the RADIUS packet's check items list.

When you activate the ldap module in the authenticate section, this is what FreeRADIUS does:

1. it tries to bind to the LDAP server as the user.
2. if it can bind, then it's a successful authentication, and a Radius-Accept packet will be sent back to the client, or else, it's a failure, leading to a Radius-Reject packet.

So how can I configure FreeRADIUS to make PEAP/MS-CHAP-v2 work with LDAP?

The important point here is that binding as the user will only work if the FreeRADIUS server can retrieve the cleartext password of the user from the RADIUS packet it received. This is only the case when PAP or TTLS/PAP authentication methods are used (and possibly also EAP/GTC). Only the TTLS/PAP method is really secure, and it is not available by default in Windows. If you want your users to connect with TTLS/PAP, you need to have them install a TTLS supplicant software, which is seldom an option. Most of the time, when deploying WiFi with WPA Enterprise securiy, PEAP/MS-CHAP-v2 is the only reasonable option.

So the bottom line is: unless you are using PAP or TTLS/PAP, you can safely remove the ldap module from the authenticate section, and actually, you should: binding as the user will not work.

If your test works when you use radtest, it probably means that the ldap module is activated in the authenticate section: it will try to bind as the user, and since radtest uses PAP authentication, it will succeed. But it will fail if you try to connect through the access point, since you are using PEAP/MS-CHAP-v2.

What you should do is remove the ldap module from the authenticate section, and make sure you activate the mschap module in both the authorize and the authenticate section. What will happen is that the mschap module will take care of authentication using the NT-Password attribute which is retrieved from the LDAP server during the authorize phase.

Here is what your sites-enabled/default file should look like (without all the comments):

    ...
    authorize {
        preprocess
        suffix
        eap {
            ok = return
        }
        expiration
        logintime
    }
    authenticate {
        eap
    }
    ...

And here is what your sites-enabled/inner-tunnel file should look like:

    ...
    authorize {
        mschap
        suffix
        update control {
               Proxy-To-Realm := LOCAL
        }
        eap {
            ok = return
        }
        ldap
        expiration
        logintime
    }
    authenticate {
        Auth-Type MS-CHAP {
            mschap
        }
        eap
    }
    ...

What about the 'No "known good" password' warning?

Well, you can safely ignore it. It's just there because the ldap module could not find a UserPassword attribute when it fetched the user details from the LDAP server during the authorize phase. In your case, you have the NT-Password attribute, and that's perfectly fine for PEAP/MS-CHAP-v2 authentication.

I guess the warning exists because when the ldap module was designed, PEAP/MS-CHAP-v2 did not exist yet, so the only thing that seemed to make sense at the time was to retrieve the UserPassword attribute from the LDAP server, in order to use PAP, CHAP, EAP/MD5 or such authentication methods.

Answer 2

I'll try to answer the OpenSSL question here: the short answer is to use FreeRADIUS 2.1.8 or above, which includes OpenSSL. It is available in Ubuntu Lucid and Debian Lenny backports (and will probably end up in Ubuntu Karmic backports too).

Here is the long answer:

Unfortunately, the OpenSSL license used to be (somewhat) incompatible with the FreeRADIUS license. Therefore, the Ubuntu people chose to provide a FreeRADIUS binary not linked with OpenSSL. If you wanted EAP/TLS, PEAP or TTLS, you had to get the sources and compile them with the --with-openssl option (as the recipe you used explains).

But recently, the licensing problem has been fixed. FreeRADIUS versions 2.1.8 or above can be compiled and distributed with OpenSSL. The bad news is that the most recent stable Ubuntu distribution (Karmic Koala) includes only FreeRADIUS 2.1.0, without OpenSSL (the same goes for Debian, since Lenny only contains FreeRADIUS 2.0.4). I checked the Karmic-backports, but it seems that FreeRADIUS 2.1.8 or above have not been uploaded there, yet (but it may be added soon, check it out here). So for now, you must either switch to Ubuntu Lucid (which includes FreeRADIUS 2.1.8) or stick to compilation. For Debian users, things are a bit brighter: the Lenny backports include FreeRADIUS 2.1.8. So if you want something very stable, and easy to install and maintain, I suggest you deploy a server with Debian Lenny, and install the backported FreeRADIUS package (it also gives you the possibility to write python modules for free, without having to recompile with all the experimental modules).

I got a certificate from http://CACert.org (you should probably get a "real" cert if possible)

There's one "gotcha" with "real" certificates (as opposed to self-signed certificates).

I used one signed by Thawte. It works fine, and users see a beautiful "valid" certificate named something like www.my-web-site.com. When the user accepts the certificate, his computer actually understands that all certificates issued by the same certificate authority should be trusted (I tested this with Windows Vista and MacOSX Snow Leopard)! So in my case, if a hacker has a certificate for, say, www.some-other-web-site.com, also signed by Thawte, then he can run a Man-in-the-middle attack easily, without any warning being displayed on the user's computer!

The solution to this lies deep in the user's computer's network configuration, in order to specifically specify that only "www.my-web-site.com" should be trusted. It just takes a minute, but most users won't know where to configure this unless you give them a clear procedure and make sure every user follows it. I still use "valid" certificates, but frankly it's disappointing to see that both Windows and MacOSX share this "bug": trusting the Certificate Authority instead of the specific certificate. Ouch...

Answer 3

According to the bug report, a simple rebuild of FreeRADIUS should fix the OpenSSH support issue. It only needs to be done once.

I'm not sure what ease of administration has to do with setup. Often, the more involved and detailed the setup, the easier it is to administer, because the setup covered all the bases. Do you mean the configuration has to be dropped on other servers easily as well? How many wireless LANs are you setting up?

Once configuired, Administration should be limited to LDAP user adds, deletes and modifies. These should be easy enough to either script with ldapmodify (et al) or find a decent LDAP graphical front end and document the processes with screenshots.

Answer 4

I ran into the same issue. I had to download the RADIUS sources and compile them myself.

Answer 5

You can use FreeRADIUS2 (with OpenSSL) + EAP-TLS + WPA2-Enterprice. Here is wery ditailed HOW-TO. Windows XP SP3 have native support for it as well as Windows 7, Android 2.3, iPhone, Symbian. But I do not know about compatibility with SLDAP in such a schem.