trying to correctly handle account passwords via ldap

[Alan DeKok]

Simo Sorce <simo.sorce at quest.com> wrote:
> As already stated these attributes should be considered internal and
> never exposed in our schema which should contain only the AD compatibile
> attributes.

  *Please* be careful with that.  Exposing the clear-text password or
NT hash is of extreme importance to a large number of people.  Many
would sacrifice "perfect" AD compatibility if it meant that they could
access the password via some schema extension.

  This change could affect deployments with 10's of millions of users.
Not Samba directly, but other applications that need the information
AD has, and refuses to expose.  If Samba can expose the information AD
won't, then Samba becomes *much* more useful to many, many, systems.

  I run into this nearly every day with wireless authentication
deployments.  The Windows laptops use PEAP (TLS + MS-CHAPv2), and AD
doesn't expose the clear-text passwords.  As a result, there are
various ways to work around the issue (e.g. ntlm_auth), none of which
are efficient or scalable.  If the NT hash infomration was available
through normal LDAP queries, then the systems would be much more
scalable, stable, and efficient.

> If our backend will (in some future) be a second ldap server, then
> THAT server will have a schema extension that will allow these 3
> attributes.

  My $0.02 is that these 3 attributes are the number one thing needed
by external applactions that AD doesn't export, but that Samba has.
Support should not be "perhaps, maybe, some time later", but "as soon
as possible", even it means AD schema extensions.

  Alan DEKok.