trying to correctly handle account passwords via ldap

[Simo Sorce]

On Tue, 2006-03-28 at 12:47 +1000, Andrew Bartlett wrote:
> On Mon, 2006-03-27 at 19:38 -0500, Alan DeKok wrote:
> > 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 strongly agree in that the administrator is the boss, not the software
> developer.  We should put in place default controls to ensure that
> passwords are harder to accidentally exposed, particularly over
> untrusted channels, but the administrator has the absolute right to the
> data in their directory.

You know too well that our source code is free to all to be studied so
that we do not have any way, not only any will, to conceal information
from admins.

A simple ldbsearch disabling modules is easy to do ...

> Password lock-in has been a tool of vendor control for too many years.

Sure, I'm not for password lock in, I just want to be compatible.

Simo.