External idmap backend(s)

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

-- 
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
Type: application/pgp-signature
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 mailing list