trying to correctly handle account passwords via ldap

[Alan DeKok]

Henrik Nordstrom <henrik at henriknordstrom.net> wrote:
> The difference is that the NT-hash-hash is only given to the RADIUS
> server for the users who have already successfully authenticated, and
> only in the hash-hash form which isn't directly useful for
> authentication

  PAP?

> You may remember that we had a similar discussion within the RADEXT IETF
> working-group some time ago regarding the use of MD5-sess within RADIUS,
> and I accept their general consensus that credentials useful for
> authentication should not leave the authentication server.

  The discussion was a little more than that.  That was one factor.
Another was that there was little to gain by pushing the credentials
to another application.

  RADIUS servers, on the other hand, have everything to gain by having
access to the NT-HASH or clear-text passwords.  It means that multiple
authentication protocols become possible, which is what customers are
asking for.  Right now, for RADIUS to AD interaction, MS-CHAP is the
only option.  This is a problem for many customers.

>  This discussions actually is no different. AD (and Samba's AD
> impersonation) is an authentication server

  I used the word "oracle" with some care.  AD is *not* a
full-featured authentication server.  That's why Microsoft ships IAS,
too.

> , and the credentials needed for
> authentication is private to the authentication server and should not
> leave the authentication server except in extraordinary conditions with
> careful thought on the implications of doing so.

  e.g. leave AD to be passed to another authentication server, like a
RADIUS server which supports many authentication protocols that AD
does not?

  I run into this every week with people using normal LDAP servers.
They believe that because LDAP supports "bind as user", it's an
authentication server.  It's not.  Despite this, they configure the
RADIUS server to "bind as user" for CHAP, MS-CHAP, etc.  When it
doesn't work, they get upset...

  The end result is that the customer deployments win.  They want to
use PAP, CHAP, MS-CHAP, EAP, and Digest, and any other authentication
protocol anyone has ever invented.  They also want to store user
information in AD.

  Samba is the *only* path where this may be possible.  Allowing the
administrator to export clear-text passwords from Samba to an external
authentication server means that the customer gets what they want.

   And, it means that Samba doesn't have to implement CHAP, EAP, or
Digest authentication.

  Alan DeKok.