updated newidmap

Volker Lendecke Volker.Lendecke at SerNet.DE
Tue Oct 3 18:27:37 GMT 2006


On Tue, Oct 03, 2006 at 02:17:02PM -0400, simo wrote:
> No my idea was to make sid2uid always allocate if possible.

The "if possible" makes it more complicated than necessary.
We had this for ages and this has led to the current mess we
have.

> The IDmap will decide if the allocation can be performed by doing a
> lookupsid to determine the sid is actually meningful.

No, this should not be in the modules. If only because then
the modules would have to link in an lsa client. The modules
should be as simple as possible.

> The allocation is obvious as choosing the backend depends on the SID.
> If the SID is from BUILTIN the backend for BUILTIN is asked, if the SID
> is from DOMAIN_X the backend responsible for DOMAIN_X is used.
> If the SID is from an unknown (in the sense that there isn't a specific
> backend) the default backend is asked (usually this will be the tdb
> backend).

No, uid/gid allocation is a global thing across all the
backends.

> This is taken in account in this case allocation will always fail.

I suspect the callers will be more complicated than
necessary with that approach.

> >  And
> > just for that purpose adding idmap_tdb would bring in too
> > much functionality for my taste.
> 
> I agree, but the solution imo is that allocation will simply always fail
> and BUILTIN users/groups will simply not be used.

Huh?

> How else could you do that?

idmap backend = domain1:idmap_rid:10000-19999 domain2:idmap_ad:20000-29999
id allocator = tdb:30000-40000:30000-40000
passdb backend = tdbsam

(ignore the syntax, you get the idea...)

BUILTIN and passdb would chew from the id allocator. All
external SIDs are statically mapped. pdb_tdb takes care of
mapping BUILTIN and its own SAM SIDs.

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/96847b8e/attachment.bin


More information about the samba-technical mailing list