Quoting Arnauld Dravet <[EMAIL PROTECTED]>:
> > 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.
>
I am having this same problem when I use the Crypt-Password attribute. Has anyone else
had this problem and overcome it?
> 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.
>
We are using PEAP with MS-CHAPv2 and LDAP and a Win2000 supplicant for testing. Do I
need to use the NT-Password attribute? Right now our directory only stores a
userPassword attribute which is encrypted.
I guess my big question is do the encrypted passwords in the LDAP directory make
authenticating impossible? Do they need to be clear-text with the setup we have? We
are running FreeRadius 1.0.0pre3 on Fedora with LDAP to store attributes (userPassword
is the only password (encrypted) attribute) and using PEAP with MS-CHAPv2 to
authenticate my win2000 client.
-Al
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
