Larry Ross lfross at ucdavis.edu
Fri Aug 21 22:59:22 CEST 2009

Hmm interesting, how were you able to divine that that is how we are storing the has values... 

-----Original Message-----
From: freeradius-users-bounces+lfross=ucdavis.edu at lists.freeradius.org [mailto:freeradius-users-bounces+lfross=ucdavis.edu at lists.freeradius.org] On Behalf Of Alan DeKok
Sent: Thursday, August 20, 2009 11:59 PM
To: FreeRadius users mailing list
Subject: Re: LDAP MSCHAP error

Larry Ross wrote:
> It appears though that there may be a bug in the string copy function of
> the rlm_ldap function (or whatever is responsible for copying the
> attributes from LDAP to Server core for MSCHAP challenge compare)   We
> noticed the truncation upon "00" and "3d" in the NT-Password hash  (so
> if the has was abc12300 or abc1233d    all you would see is abc123)

  The OpenLDAP API assumes that the returned values are text.  If you
want to store *binary* data, then FreeRADIUS has to use a different API
to query for the data.  And *before* it does the query it has to know
which values are binary, and which ones are text.

  Or, you can do what everyone else does.  Store the NT-Password hash as
 a string of 32 hex numbers.  Storing it as a binary blob of 16 bytes
just causes problems.

  Alan DeKok.
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

More information about the Freeradius-Users mailing list