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