yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...

[Alan DeKok]

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.