Maybe this will help:
In eap_leap.c:219 there's an if statement looking for the normal password attribute. If that's not found according to the comments must be an NT-Password. The value that's being assigned to the ntpwdhash is coming from password->strvalue. I ran a test an in the normal case (freeRadius pulling the NT-Password from the ntPassword attribute with the '0x'), the strvalue seems to be in bytes and when running the other scenario, the value is in ASCII. I'm going to test to see if I convert that string back into bytes if it works...
BTW, I can move this thread to the development list if you want.
--J.
On Feb 14, 2005, at 1:58 PM, Alan DeKok wrote:
Jason Howk <[EMAIL PROTECTED]> wrote:No go. I put in some additional debug statements and recompiled
eap_leap and I'm seeing some interesting results. If I follow what is
described below, the output from the call to
eapleap_ntpwdhash()(eap_leap.c:198) is totally different if I revert
back to using the LDAP ntPassword attribute with a valid octet string
that starts with '0x'. The passwords used in each test are exactly the
same so I would expect that the password to be hashed should be
equivalent regardless of method. This isn't happening...
Ok.. I'm not sure what else to suggest.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
