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