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