[PATCH] Local password database
abartlet at samba.org
Tue Jul 18 06:30:09 GMT 2006
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
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 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 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
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060718/263a801d/attachment.bin
More information about the samba-technical