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