> That shouldn't be necessary.
well i'll double check tomorrow, i've done so many tests so far that maybe it's
not usefull anymore .. I know for sure that in debug logs, it shows the password
grabbed as {CRYPT}xxxxxxx.
> > rlm_ldap: Adding userPassword as Crypt-Password, value { & op=21
>
> That value doesn't look like a password.
yes i know, and i think that's the problem. When i just use password_attribute
it grabs the whole password (displayed in debug logs), and not anymore when i
use the mapping for Crypt-Password, of course on the same ldap attribute for
both. i thought the '{' displayed was from the first caracter it met ( from
{CRYPT}xxxx ) so i tried to re-enable the password_header field in the ldap
section of radiusd.conf, without any good result.
> That value should have a "0x" in front of it.
That's what is told in the radiusd.conf yup .. could that change something to
the rest of the problem ? I'll check the smbldap-adduser.pl script i use to add
windows users in the ldap tree. Anyway windows workstations work perfectly
without the 0x.
> LDAP doesn't do crypt'd passwords. The server does. And the server
> doesn't care where that crypted password came from.
Yup, but i was trying to find the moment where the radius Crypt-Password
attribute was used in the ldap mapping file and from the ldap directory, to
check why it doesn't grab the password from the user entry.
--
Arnauld Dravet
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
