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@lists.freeradius.org [mailto:freeradius-users-bounces+lfross=ucdavis.edu@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