OpenLDAP and Samba4 - password sync as a first step?

[Andrew Bartlett]

On Wed, 2013-04-17 at 14:58 -0700, Howard Chu wrote:
> Hey there list, Andrew... I keep meaning to have this discussion with Andrew 
> and then it always slips by, but this time for sure.
> 
> I'll keep this short - my colleagues at Symas want to know what it will take 
> to bring OpenLDAP up to date to be usable directly by Samba as a first-class 
> recommended option, not just "yeah that should work but..." I've reviewed some 
> of the previous discussions on this topic in the archives, but I suspect some 
> of those points are now out of date.

I've been thinking about ways we could better work with OpenLDAP, as I
talk more and more with Samba users who can't just drop their existing
configurations, or don't want to migrate their unix-like world to AD,
even if provided by Samba.

There are many tools to sync directories, and while I dislike that as a
concept, they are part of the world we work in.  What they generally
miss is a good way to handle passwords, and there is where I thought we
might be able to make some positive progress. 

In particular, I'm wondering about having Samba sync either the
plaintext password (when sent to us during a password change) or an
appropriate password hash to OpenLDAP, and have OpenLDAP send us the
plaintext password if it does the change. 

For real-time both-directions sync of real passwords with policy
enforcement:

I'm thinking something like this:
 - password change proposed to Samba
 - verify Samba would accept password
 - (maybe - transactions over network ops are bad) start Samba
transaction 
 - ask openldap to change password
 - set password in Samba
 - (maybe) commit samba transaction 

and in the reverse:

 - password change proposed to OpenLDAP
 - verify OpenLDAP would accept password
 - (maybe) start OpenLDAP transaction
 - ask Samba to change password
 - set password in OpenLDAP
 - (maybe) commit OpenLDAP transaction

I would propose that we use an extended operation (perhaps based on the
existing one) to do the password change, but extended so that OpenLDAP
and Samba know if it is a password change or set, but without seeing the
old password. 

That way, OpenLDAP and Samba can both veto a password, keep applying
policy and hopefully things can't get out of sync.

For situations where Samba is the master, or where AD is the master, and
Samba is just part of a broader AD domain, I wondered if we could have:

 - password change proposed to samba
 - verify Samba accepts password
 - send the aes256-cts-hmac-sha1-96 hash to OpenLDAP
   (this hash chosen as all current AD servers can generate it, and it
is salted unlike previous AD keys)
 - set password in samba

For replicated from another AD:
 - when password change noticed
 - send the aes256-cts-hmac-sha1-96 hash to OpenLDAP

For the reverse:
 - password change proposed to OpenLDAP
 - send password change to samba
 - wait for return of aes256-cts-hmac-sha1-96 hash

What do you think?  Once password changes 'just work', I think some of
the other pain points become much easier, for dual-directory
situations. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org