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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html