External idmap backend(s)

[Matthew Mastracci]

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. 

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.

I think that the following parameters would suffice:

ldap idmap groupobjectclass = "posixGroup" (default: sambaIdmapEntry)
ldap idmap accountobjectclass  = "posixAccount" (default: sambaIdmapEntry)
ldap idmap allowcreatemapping = false (default: true)

Would this be a reasonable compromise?  I don't mind dumping the backend 
and scripts if I can make it work this way.

Thanks,
Matt.