I am experiencing the following oddness I am hoping someone can shed some light on...

We are using FR 2.X and LDAP for MSCHAPv2 authentication.  We are storing the NT-Password Hash within LDAP, utilizing ldap.attrmap to map our LDAP variable to "NT-Password"

So when an MSCHAPv2 based Auth comes in all is well, the mschap module sees mschap attributes, sets Auth to MSCHAP.  rlm_ldap dives into LDAP and locates and maps "NT-Password"  properly.  All is well.... ALMOST...

For a few lucky accounts this process comes to a halt, upon inspection we noticed that the NT-Password being copied by rlm_ldap was being truncated

[From Debug output]

rlm_ldap: unicodePWD -> NT-Password == 0x6f183bc46904

This is super short...  Look at a successful auth

rlm_ldap: unicodePWD -> NT-Password == 0xb31b12345aca32aaa607430cb7acdcb1

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)

Your input is greatly appreciated.

Thank you

Larry