PAP and NT-hashed password

[Alan DeKok]

On Jan 2, 2015, at 7:26 AM, sb <superabx at gmail.com> wrote:
> Upgraded to 2.2.6, nothing changes.

  Because the LDAP database is storing the NT password in the userPassword field.

> [local] Added User-Password = 1D*********************9B in check items

  Which looks to be 32 hex characters.  i.e. the NT password.

  Here’s a simple question.  Is the “correct” password for the user really “1D…”, or is it something else?

> [local] looking for check items in directory...
>   [local] sambaNtPassword -> NT-Password == 0x31**********************************************************42

  Which is the *previous* password (1D…) converted to hex.  i.e. the “sambaNtPassword” field doesn’t look like it’s actually an NT password.  It’s something else.

> I can not understand why is this:
> 
> [local] Added User-Password = 1D*********************9B in check items
> 
> There is nothing of User-Password in ldap.attrmap,

  The LDAP module adds it automatically.  “userPassword” in LDAP maps to “User-Password’ in RADIUS.

> why the radius adds it from sambaLmPassword?

  It doesn’t.  I have no idea why you think that’s happening.

> I can not put cleartext passwords in LDAP, so I have to work with NT-hashed passwords only. 

  Then make sure to put an “{nt}” prefix in front of them in LDAP.  I already said to do this.

LDAP should have “userPassword” with value “{nt4}1D…."

> So, how to tell the radius that User-Password and Cleartext-Password are empty and it has to operate with NT-Password?

  You don’t.  What you’re doing with LDAP is incorrect.  The data you’re putting into the userPassword field in LDAP is *wrong*.  The data that’s in the sambaNtPassword field is VERY WRONG.

  You can work around it by doing the following.  In “sites-enabled/default”, look for the “authorize” section.  It should have a line which is “ldap”.   After that line, add the following:

	update control {
		NT-Password := “%{control:User-Password}”
		User-Password != *
	}

  This will make the NT-Password have the value of the userPassword field.  And then it deletes the *wrong* User-Password.

  But the underlying issue is that the data in LDAP is wrong.  You’re putting NT-Passwords into the userPassword field.  That’s wrong.

  Alan DeKok.