Configuring LDAP lookups for EAP and inner-tunnel
Using freeradius 2.1.7 to authenticate wireless users via eap, checking against an ldap server. Its working fine, but I'm seeing an ldap lookup for each part of the eap conversation. This leads to something like 13 LDAP lookups for each valid eap authentication sequence. I did check the archives and found one thread about this same topic from a user of freeradius 1.x, and the comments there were that it would be much better in 2.x. via the inner-tunnel stuff. And I see in the eap_modules_changes page on the wiki, that Autz caching should resolve this for me. So I moved my ldap lookup configuration from the authorize section of the sites-enabled/default file into the inner-tunnel file. But I still see the same number of ldap queries per eap session. Next I tried to enable the cache section in the eap.conf for tls, but I have not seen that make any difference in the ldap calls. And from the comments I assume that just for session resumption, not initial authentication. Could someone give me a pointer/hint as to how to configure eap/ldap to cut down on the number of ldap queries. Any help greatly appreciated. Jeff
Jeffrey Collyer wrote:
So I moved my ldap lookup configuration from the authorize section of the sites-enabled/default file into the inner-tunnel file. But I still see the same number of ldap queries per eap session.
Then it's still doing LDAP lookups in the "default" virtual server. Or, you have LDAP-Group checks in the "default" virtual server.
Next I tried to enable the cache section in the eap.conf for tls, but I have not seen that make any difference in the ldap calls. And from the comments I assume that just for session resumption, not initial authentication.
Yes.
Could someone give me a pointer/hint as to how to configure eap/ldap to cut down on the number of ldap queries. Any help greatly appreciated.
The default configuration does *not* do LDAP lookups. So... use the default config, and then enable LDAP lookups in the "inner-tunnel". Alan DeKok.
On 9/17/10 11:09 AM, Alan DeKok wrote:
Jeffrey Collyer wrote:
Could someone give me a pointer/hint as to how to configure eap/ldap to cut down on the number of ldap queries. Any help greatly appreciated.
The default configuration does *not* do LDAP lookups. So... use the default config, and then enable LDAP lookups in the "inner-tunnel".
setup information that I failed to explain properly the first time : freeradius 2.1.7 is used to authenticate wireless users with eap-tls with the users authorization to connect being the cn of the certificates they have on their client. That cn is checked against ldap for an attirbute 'wirelessAccess'. (and I know that the certs outer identity can be set to anything, but for this test its valid on the connecting machine.) I started with a default configuation and added ldap to it in the sites-enabled/default file's authorize section. And it worked authenticating the client, but with many (about a dozen) ldap lookups. I then moved the ldap line over to the sites-enabled/inner-tunnel file and removed it from default. The configuration would run, but would not validate against ldap. Then I realized that the 'tls' section of the modules/eap.conf file doesn't have a virtual_server directive, but even after putting that in the 'tls' section, its still doesn't run an ldap query when I try to authenticate. So my assumption is that the eap module doesn't use the inner tunnel for tls. If this is not the case, then I can certainly provide the debug output from 'freeradius -X', but I don't want to waste the bits if my assumption is true. Thanks Jeff
Jeffrey Collyer wrote:
setup information that I failed to explain properly the first time : freeradius 2.1.7 is used to authenticate wireless users with eap-tls
Well... that would have been nice to say.
I started with a default configuation and added ldap to it in the sites-enabled/default file's authorize section. And it worked authenticating the client, but with many (about a dozen) ldap lookups.
Because there are about a dozen EAP packet exchanges.
Then I realized that the 'tls' section of the modules/eap.conf file doesn't have a virtual_server directive, but even after putting that in the 'tls' section, its still doesn't run an ldap query when I try to authenticate.
Because the "virtual_server" directive doesn't belong in the "tls" section.
So my assumption is that the eap module doesn't use the inner tunnel for tls.
Yes. The solution is to move the LDAP checks to the "post-auth" stage. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
So my assumption is that the eap module doesn't use the inner tunnel for tls.
Yes.
The solution is to move the LDAP checks to the "post-auth" stage.
Just something for the archives... Or *after* eap in authorize{} where eap is called by: ---- authorize { .... eap { ok = return } ldap .... } ---- It is handy to have ldap in the authorise section as you can then put your MAC address blacklists into LDAP too. The downside is that if you want to then do host based VLANing (using Ldap-UserDn) in post-auth you have nothing to work with as 'ldap' was not invoked on the final EAP frame. I work around this by having a perl caching module (alas the experimental FreeRADIUS one does not quite seem to be suitable for what I need, from what I can tell): ---- perl cache_ldap-userdn { module = ${confdir}/cache_ldap-userdn.pm func_authorize = authorize func_post_auth = post_auth } ---- The perl module is available for now at: http://stuff.digriz.org.uk/cache_ldap-userdn.pm Then my virtual server looks like: ---- authorize { .... eap { ok = return } # typically this is the *last* thing in your authorize{} # section as under the 'if()' clause you would decide to # reject the user or whatever, saving you going through # the whole EAP process and letting you reject early. ldap if (ok) { cache_ldap-userdn } } post-auth { .... if (!(Ldap-UserDn)) { cache_ldap-userdn } ldap .... } ---- Now you get all the benefits of EAP with 'ok = return' but do not lose Ldap-UserDn due to skipped LDAP module calls. The perl script should be straight forward to let people cache other attributes too and what not, hopefully simple enough for everyone to amend to their needs. Suggestions for improvement welcomes, it's something I put together in an hour last week. As a statistic, it seems an EAP session for us now has two LDAP lookups rather than 10+. The first one is for checking if the MAC is blacklisted, the second one works out (via a group membership) which VLAN the user should be in. Yay. Email me if you need any help with my perl module. Cheers -- Alexander Clouter .sigmonster says: Given my druthers, I'd druther not.
participants (3)
-
Alan DeKok -
Alexander Clouter -
Jeffrey Collyer