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

[Arran Cudbard-Bell]

Alan DeKok wrote:
> 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.

Yes, it is duplicate functionality. Lots of our configuration files are 
still based on CVS versions from when FR 2 was being developed, I should 
really merge them with the standard 2.0.3 configs at some point.

I just couldn't understand why the PAP module wasn't processing the 
header on the User-Password, and I know the autoheader option works for 
us with rlm_ldap. It's actually very useful because it'll allow the 
migration from crypt *sigh* to ssha1 at some point in the future, but if 
rlm_pap does the same thing then i'll switch to that.

> 
>>>  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.
> 
> 
>   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.


But it doesn't appear to be... you have got the autoheader option set in 
the PAP module?

         pap {
                 auto_header = yes
         }

Doesn't matter where it's set for testing, it just needs to be set 
*somewhere*.

*nothing* will work until you get the hash into the correct attribute 
with the header stripped off.

Fudging it by creating a static mapping userPassword -> SSHA-Password in 
ldap.attrmap won't work because the header will still be present in the 
hash...

If you really stumped something like:

authorize {
	ldap
	if(ok && ("%{control:User-Password}" ~= /^{ssha}(.*)/i)){
		update control{
			SSHA-Password := "%{1}"
		}
	}
}

Will do the work of the LDAP / PAP module. But it's a bodge, really 
rlm_pap should be doing that.

>> 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.

We have the LDAP servers in a DNS round robin. Does FR resolve the 
hostname each time a new connection is established, or will it resolve 
it once during startup when the configuration entry is parsed?

Thanks,
Arran