OpenLDAP and Samba4 - password sync as a first step?

Howard Chu hyc at highlandsun.com
Sat May 18 11:15:04 MDT 2013


Andrew Bartlett wrote:
> 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.

Sounds like a good first step. One question, Microsoft already provides an 
agent that runs on AD DCs to export password modifications (to a corresponding 
Unix listener). Should we use the same protocol as this agent? I've looked at 
it a few times, and thought about implementing the listener directly in slapd.

> 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
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


More information about the samba-technical mailing list