External idmap backend(s)
abartlet at samba.org
Tue Feb 6 22:10:47 GMT 2007
On Tue, 2007-02-06 at 14:57 -0700, Matthew Mastracci wrote:
> Andrew Bartlett wrote:
> > On Mon, 2007-02-05 at 13:40 -0700, Matthew Mastracci wrote:
> >> The big reason we need this is to implement an LDAP mapping that is
> >> close-but-not-quite-the-same-as the current idmap_ldap stuff, but is
> >> easier to maintain as a bunch of shell scripts than writing and
> >> maintaining a new back-end that won't ever make it into the tree and
> >> updating a patch for it.
> > Is is possible that with a few extra parameters, your setup could be
> > incorporated into the standard? Or, why can't you use the standard
> > mapping?
> I think that extra parameters would make this work. I've been
> maintaining my patch for a while and haven't revisited the problem for
> some time, so I'll admit that I haven't checked out what it would take
> to make it work with the alternate backends since last year until now.
> The big difference between our setup and the standard LDAP idmap backend
> is that our UID/GIDs are allocated at user creation time using the
> posixAccount attributes through our user creation scripts to centralize
> the operation.
> We needed uniform IDs and full winbind integration across a number of
> systems. The current winbind LDAP idmap backends all use the
> sambaIdmapEntry object type instead of the posixAccount attributes on
> the user objects. This unfortunately prevents us from using the current
> idmap backends.
That objectClass is intended to be auxillary, and can therefore be added
to any entry, just like the sambaSamAccount.
> I think we could get things working if we could customize the LDAP
> searches, or at least be able to change the objectClass that is
> currently hardcoded to LDAP_OBJ_IDMAP_ENTRY to
> LDAP_OBJ_POSIXACCOUNT/LDAP_OBJ_POSIXGROUP. We'd also need to disable
> the automatic ID allocation code, since all servers but the domain
> controller can only read the mapping information and cannot write to the
> LDAP tree.
That should simply be a matter of allowing writes to fail gracefully.
Perhaps they already do?
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/20070207/983328ce/attachment.bin
More information about the samba-technical