I appreciate all the replies so far. I'm responding to several at once here, in order of appearance in my mail spool ... On Sat, 29 Mar 2008, Arran Cudbard-Bell wrote:
I Noticed from that sample hash, your passwords have the correct {SSHA} prefix, this means you should be able to use
ldap { auto_header = yes
}
And the server will automatically write the hash to the correct internal attribute. ...
I will definitely give that a try on Monday morning. I wasn't aware that the ldap module also had an auto_header parameter. I have it set for the pap module already, but will try with the ldap module and report back.
I have no idea what password_radius_attribute is ?? Is that a legacy configuration item ?
I don't think so. I only learned about it this week, though that isn't to suggest that it wasn't around previously. I learned about this from reading doc/rlm_ldap that ships with freeradius-server-2.0.3. That file says the following about this parameter: # password_radius_attribute: Defined the RADIUS attribute where # the extracted user password will be stored to. Can be used to # set it to NT-Password or any other similar attribute instead of # the default # # default: User-Password # # password_radius_attribute = "NT-Password"
If your password is indeed stored in the LDAP 'userPassword' attribute which is the default then: ... password_attribute = userPassword should suffice.
Agreed, but I wasn't able to get even radtest working against users in LDAP with that. I came to understand that this was because in that case rlm_pap wasn't receiving the password in User-Password and therefore it was comparing the plaintext password from the authentication request with the encrypted password from the LDAP backend. Of course that wouldn't match.
The other way you can do this is by using the LDAP module as an authentication module. When used in the authentication section it'll attempt to bind to the LDAP server using the users UID and Password. I wouldn't recommend it in your case though, as binds are comparatively slow, and it'll only work with PAP.
That is what we have in place now, with FreeRADIUS-1.1.6, and which works, but indeed is giving us performance headaches. I wasn't aware that binds are slower than queries, though I suppose it makes sense that they would be, and I don't doubt that a different configuration would have it working better. On Sat, 29 Mar 2008, Alan DeKok wrote:
It really depends on what you're doing. The recommendations against setting Auth-Type are there because almost everyone gets it wrong. There *are* situations where setting it is the right thing to do. But it's almost always wrong...
I can accept that, and I'm not convinced that it's necessarily the "best" way to get what I want in our installation (after all, what I really want is the LDAP query to provide the *authorization*, and let the authentication be done by the PAP module). However, at the time I did it, it seemed to be the only thing I was able to do to get it working against LDAP data at all, after much research and trial and error. I din't feel I could argue very much with "it works". ;-)
[ASIDE] With the older versions of FreeRADIUS we're having performance problems with the authentication. ...
Run it in debugging mode to see what the problem is. ...
To be honest, my interest now is primarily in getting the setup I've been working on with 2.0.3 working correctly and replacing the old setup with that. I know I'm close and I feel that I'm aiming in a more technically "correct" direction, so it seems better to me to focus my efforts on that right now. It might still be interesting just to _know_ what's slowing the RADIUS server down, though.
There isn't really a whole lot that can go wrong with the server. If it's waiting more than 30 seconds to respond, then the likelihood is that it's doing DNS lookups, and DNS is broken.
Hrmmm... I have "hostname_lookups = no" on both my existing (1.1.6) installation and the new one I'm working on (2.0.3), but of course *some* DNS lookups would still be expected (I have multiple LDAP servers configured, by hostname, for example), and although I don't have any other evidence that there is anything at all wrong with our DNS resolvers, I have to admit that I hadn't even considered this possibility, and it obviously shouldn't be overlooked. I could rule it out (or work around it) by setting up a caching resolver on the system. I'll consider doing that if I'm no further ahead with 2.0.3 by the end of Monday.
You may need to install "sites-available/inner-tunnel".
I did. I spotted the hanging sym-link, and references to it in earlier discussion on this mailing list. Once I'd gotten that done, I thought I'd gotten it all in place, but I'm still stuck. :-(
WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! Cancelling invalid proxy request.
Is this caused by the following in raddb/sites-*/inner-tunnel?
Yes. The message is there to warn people about common misconfigurations. Don't worry about it.
Thanks.
The text "User-Password" appears in exactly the following places in my raddb directory (not counting comment lines):
That's not the issue. The issue is that the rlm_ldap module is reading the "userPassword" ldap field, and creating a User-Password attribute. It could really be fixed.
By patching rlm_ldap, you mean, or by adjusting my configuration?
It doesn't work because the PAP module isn't doing anything. The PAP module *should* be taking the crypt'd password, and doing something useful with it. (See "man rlm_pap")
Agreed. I'm pretty sure that it was after reading "man rlm_pap" that I went on a search that led me to the password_radius_attribute parameter in my configuration for the ldap module (which I'm told in a later message quoted below is not recognized by rlm_ldap anyway). The exact sequence of what I read when is a little blurry by now, I have to admit.
Yes... because it's behaving differently. See the debug output for what differences there are.
Ok, but what I'm stuck on is *why* the differences are there. I don't doubt I've done something wrong, but I'm unable to figure out what it is that I've done wrong.
and radeapclient against a user in the users file (success using md5 as the default_eap_type, but not ttls),
Because you're putting a clear-text password in the "users" file, not a SSHA encrypted blob like you're getting from LDAP.
Yes.
Compare apples to apples, not apples to oranges. If you put the *same* SSHA blob you get from ldap into the "users" file, then it would likely behave differently...
Ok, and then I'll need to put the blob in a SSHA-Password attribute, correct? (I will try this on Monday, if I haven't found or gotten an answer to it already by then). In which case I'm left still trying to get the ldap module to do the same, which I thought I had done, but perhaps haven't done correctly? On Sat, 29 Mar 2008, Phil Mayers wrote:
I don't have a copy of 2.0.3 handy, but this looks like a bug to me at ~line 383 of rlm_pap.c:
case PW_PROXY_TO_REALM: { REALM *realm = realm_find(vp->vp_strvalue); if (realm && !realm->auth_pool) { return RLM_MODULE_NOOP; } break; }
I've compared the above (from 2.0.3) with the same section of code in rlm_pap.c from 1.1.6: 384 case PW_PROXY_TO_REALM: 385 { 386 REALM *realm = realm_find(vp->strvalue, 0); 387 if (realm && 388 (realm->ipaddr != htonl(INADDR_NONE))) { 389 return RLM_MODULE_NOOP; 390 } 391 break; 392 }
Shouldn't that be:
if (realm && realm->auth_pool)
i.e. if the realm is known/real *and* has servers i.e. isn't local, then no-op?
I would certainly be willing to act as a Guinea-Pig for this on Monday. What you're saying makes sense to me and I'd certainly like to see that the solution is this simple. If no one says outright that the above code (from 2.0.3) is correct as it is, I'll invert the condition on Monday morning and try some more. On Sat, 29 Mar 2008, Phil Mayers wrote:
First things first - can I clarify that your goal is to have users, using EAP TTLS/PAP, authenticating against LDAP entries. The LDAP entries are of the form:
dn: cn=j_doe,ou=... cn: j_doe userPassword: {SSHA}bhjqewhtqothethwe==
Correct?
Yes.
...you've trimmed the debug lines above this - not helpful, ...
Sorry. I didn't expect those lines would be helpful with identifying the source of the problem. They looked to me like "everything is normal up to here ..." I can repost that, if you think it would help.
but I think I can see the problem:
... ++[ldap] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop
Notice that "pap" does a no-op here. As far as I can see, rlm_pap should update the request, ...
Your point above. I'm nowhere near being a RADIUS expert (no way I could have *found* that myself), but at least I feel I'm following along ... :-)
WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! Cancelling invalid proxy request.
...try removing the "Proxy-To-Realm" stuff - it's not needed in your case.
I can do that, but Alan's point above is that this message is harmless, and is not relevant to my problem. Either way is fine with me if I get the intended result, though certainly "cleaner" is "better".
Replacing User-Password in config items with Cleartext-Password. Please update your configuration so that the "known good" clear text password is in Cleartext-Password, and not in User-Password.
These warnings appear because the Auth-Type defaults to Local
because rlm_pap did a noop above?
auth: type Local auth: user supplied User-Password does NOT match local User-Password auth: Failed to validate the user.
...and the "Local" auth type is handled internally by the server core, and doesn't do the magic required to recognize the {SSHA} in the User-Password config item.
Right, that's rlm_pap's job.
Login incorrect: [j_doe/*SANITIZED*] (from client wireless-mcconnell
...hence login fails.
and my users complain. :-(
Much later in your email, you list the output of a radtest against LDAP. Because that isn't EAP-TTLS, there's no tunnel and thus the rlm_pap bug isn't triggered.
I think I'm still following ...
radeapclient against a user listed in the users file still performs the ldap query for authorization (I actually don't want that; I'd like the users file to over-ride the LDAP listing, if an entry is matched in the users file),
In that case, you will need to configure the server appropriately - in older versions of the server you'd do this:
authorize { preprocess files Autz-Type LDAP { ldap } }
Yes.
...and in users:
j_doe Cleartext-Password := "foo"
DEFAULT Calling-Station-Id == "0011.2233.4455", Auth-Type := Reject
DEFAULT Autz-Type := LDAP
Yes.
...or something like:
authorize { preprocess redundant { files ldap } }
I only learned about "redundant" this week. I expect that will be useful to me for listing multiple LDAP servers (with parallel copies of the data), but no, I don't have this.
...in 2.x versions of the server you might want to use "unlang"
I'll re-read that, but will worry about this matter only after I get the authentication working as I intend.
In my opinion, radeapclient is not terribly useful.
I would recommend compiling eapol_test from the "wpa_supplicant" package; it can do a full EAP TTLS/PAP request against a radius server.
Thanks. I'll set that up for testing.
As has been pointed out in another email, you have set:
modules { ldap { ... password_radius_attribute = "SSHA-Password" } }
yes.
"password_radius_attribute" is not a valid config item for the LDAP module; the ldap module will be ignoring it. You don't need it.
Ugh! See above for where I learned about that parameter in the first place (doc/rlm_ldap in the freeradius-server-2.0.3 source tree). Here I was under the impression that I was doing exactly as needed! :-( Indeed the string "password_radius_attribute" shows up _only_ in doc/rlm_ldap, and not in any source (or header) files. I should have thought to check for that in the first place ... To summarize, the main things I need to look at Monday are: - invert the PW_PROXY_TO_REALM test in rlm_pap.c, unless it's declared that the test is correct as it is. - confure "auto_header = yes" for the ldap module. - Consider adding a caching DNS resolver to the systems running RADIUS servers. - Test with an SSHA hash as the password in the users file, and understand exactly what attribute it needs to be in. Make sure that the ldap module is placing the users' passwords in that attribute. -- ---------------------------------------------------------------------- Sylvain Robitaille syl@alcor.concordia.ca Systems and Network analyst Concordia University Instructional & Information Technology Montreal, Quebec, Canada ----------------------------------------------------------------------