updated newidmap

[Volker Lendecke]

On Tue, Oct 03, 2006 at 01:59:54PM -0400, simo wrote:
> Uhmm mapping often requires allocation, I don't see what do you mean.

Right, but as we agreed not to do automatic allocation
guarded by a magic flag, sid2uid would not allocate anymore.
So it's two calls to the idmap api anyway.

> > Proposal: Why don't we have two separate module interfaces,
> > one for id mapping and another one for allocation. idmap_tdb
> > and idmap_ldap would support the set_mapping call, whereas
> > idmap_ad and others would not.
> 
> Can you elaborate some more?

A lot of the confusion in my head came from mixing up the
two tasks allocation and mapping. If we go to have different
backends per trusted domain, it is not entirely obvious
which one the allocations would come from. This is why I
would like to separate out that task.

For example in the pure appliance scenario you might have
only local allocation for the machine's SAM, whereas
everything else comes from a centrally managed LDAP server.
Or each of the boxes is able to ask the central LDAP server
for new IDs, but for specific domains idmap_ad would kick
in. All sorts of setups.

A popular setup might be to have _only_ idmap_rid/idmap_ad.
How would you do the allocation for the local stuff? pdb_tdb
would take care of BUILTIN/LOCALSAM, but it would not be
able to allocate IDs, because none of the backends can. And
just for that purpose adding idmap_tdb would bring in too
much functionality for my taste.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061003/76515c98/attachment.bin