Sylvain Robitaille wrote: ...
ldap { auto_header = yes ... 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 would very much prefer that the PAP module be used for the password mangling, rather than rlm_ldap. The code in the PAP module does more, and is more used than the similar code in rlm_ldap. I think that functionality will be removed from rlm_ldap.
have no idea what password_radius_attribute is ?? Is that a legacy configuration item ?
Yes.
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:
I've deleted that text from the documentation. The configuration item hasn't been in rlm_ldap for a long time.
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.
You need to tell FreeRADIUS *how* you have encrypted the passwords. If there's a {ssha} header on the password, then the PAP module should figure it out.
It might still be interesting just to _know_ what's slowing the RADIUS server down, though.
30 second delays are almost always DNS.
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),
Yes. That configuration item controls IP address -> hostname lookups for printing. It has *no* effect on hostname -> IP mapping, such as looking up ldap servers by hostname.
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.
Run the server in debugging mode. If there is a problem with DNS, you will see it *stop* for 30 seconds while it looks up a name.
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?
Patching rlm_ldap, probably. The "userPassword" should be mapped to User-Password via ldap.attrmap, just like everything else.
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.
It may be the bug in rlm_pap. Grab a current CVS snapshot, and see if that works any better.
Ok, and then I'll need to put the blob in a SSHA-Password attribute, correct?
Yes. And it will likely work. But... the LDAP module is putting it into the User-Password attribute. So you might want to test that, too.
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.
$ man unlang You probably want "redundant-load-balance". It's a bit of effort to type, but it results in a pretty robust system.
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.
Grab the updated code from CVS.
- confure "auto_header = yes" for the ldap module.
I really don't think that's necessary. If you're not proxying, then the PAP module *should* take care of fixing the password up.
- Consider adding a caching DNS resolver to the systems running RADIUS servers.
Yes.
- 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.
Also, test with a User-Password := "{ssha}...". Check that the PAP module "fixes" it, and turns it into a SSHA-Password attribute. Alan DeKok.