[PATCH] Local password database

[Andrew Bartlett]

On Fri, 2006-07-14 at 10:34 -0400, simo wrote: 
> On Fri, 2006-07-14 at 16:15 +1000, Andrew Bartlett wrote:
> > This patch, developed in my efforts to have Samba4 back onto an arbitary
> > LDAP server, provides a local password database, for remote entries.
> > 
> > The local_password module takes advantage of the partitions module to
> > redirect password-like attributes to a different partition.  There are a
> > few use cases:
> >  - Testing against AD.  We could aim the main partition at AD, and use
> > the passwords module to keep local passwords, where we can put them with
> > SamSync (as they are not available to read on LDAP)
> > 
> >  - Backing Samba4 onto a non-LDAP authentication system.  I am working
> > with a system where the passwords are not in LDAP, but are instead
> > synchronized between all systems by another deamon.  This system ensures
> > multi-master operation (better than what OpenLDAP can do), because with
> > passwords, the last writer always wins.  
> > 
> > I was asked to post these patches for seperate review, so here is the
> > local_password module, and it's required changes. 
> 
> 1 comment and 1 questions.
> 
> You seem to not check if there is anything in the msg after you remove
> all passwords elements on modify.
> 
> Why do you keep the passwords in the same ldap tree through a partition?
> I do not think they should be exposed at all directly, I would just open
> a completely separate ldb on module initialization and store the
> passwords there.

That is entirely possible.  This was easier at the time, but as the
partitions module shows, it isn't that hard to open a new database. 

> Why don't you create an alternative password_hash module in this case?
> It would make more sense to me to handle all password related stuff in a
> single module and choose which module to use based on what we need to
> do.

I did not wish to duplicate that much carefully constructed code.  I
feel that the task of redirection is separate from the task of hashing
the password.

> > The main questions I have are: should I commit this module, and should
> > it be enabled by default?
> 
> I am not sure this is the right way and we are adding a lot of stuff
> about passwords with our custom fields that we will need to change
> later, I'd like to use the same attribute names Windows use for
> compatibility so that you do not even have to strip them out before
> committing changes (we want an eventual AD backend and our LDAP to be in
> sync don't we?).
> As we are storing the passwords in a separate db it does not matter
> whether the storage format is the same or not.

This reminds me, we still have that crypto challenge to crack on DRSUAPI, so we can stop guessing...

> I would not definitely not enable this by default. I see all the LDAP
> backend stuff as optional. I want to be sure we do not depend on it.

I understand this, however I'm a bit worried that non-default codepaths
will be lost in the next ldb rewrite. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060718/263a801d/attachment.bin