algorithmic, IDMAP_BOTH and rfc2307 attributes for s4 id-mapping?

[simo]

On Tue, 2012-10-16 at 10:38 +1100, Andrew Bartlett wrote:
> On Mon, 2012-10-15 at 20:59 +0200, Gémes Géza wrote:
> 
> > Hi,
> > 
> > What about the following approach: read the rfc2307 attribute from the 
> > directory and disregard the fact that it is a uidNumber or gidNumber and 
> > treat it as both (of course one must be sure, that they don't overlap 
> > (I've made them equal with the RID which guarantees uniqueness))
> 
> This is something I've thought about for a while, but not implemented
> yet.
> 
> What I want to do is, if the admin wants to do this (has a policy where
> they ensure that the spaces are unique, for at least some users) is to
> have a schema extension of objectClass sidToIdMap and attribute
> idMapBothUidGid.  If set to TRUE, then we know that the uidNumber is
> also valid as a gidNumber, and vice-versa.

I am still unconvinced we need this mostly due to the 'extend the schema
issue', however I want to think a bit more about it.

> It wouldn't change the meaning of a gidNumber on a posixAccount, because
> this needs to either match the primaryGroupID or is trying to match the
> behaviour of an external posix domain where it really is the primary
> group (where we don't have user-private-groups).  Naturally, if that
> isn't the case it can be set to the same value, for even better client
> behaviour.
> 
> That handles the 'admin really cares about their uid/gid numbers' case. 
> 
> For the algorithmic case, I want us to use the trustPosixOffset
> attribute, and the RID.  This seems to be the 'official' (if very rarely
> used) distributed whole-forest idmap_rid-style mapping in AD.

Yes I had this in mind precisely, and we should definitely use it.

> http://msdn.microsoft.com/en-us/library/cc223789%28prot.20%29.aspx
> 
> Issues with this include that the builtin rids start fairly low
> (possibly in a clash range with other values).  It also isn't clear what
> the implied maximum number of users in a domain (before hitting the next
> domain) is.  

No ceiling afaik, however the rids are offset by the posix offset so
their absolute value shouldn't really matter.

> However, like idamp_ldb:use rfc2307 it might have to be off by default
> (drastically limiting it's utility), because we could clash with some
> existing users.

Not on new domains, and on the few upgrades you should just ask what is
the admin want to set the trustPosixOffset so that new ids do not clash.

If some cases fall off, well too bad, we can't handle just every single
corner case.

> Actually, I would really like 'idmap_ldb:use rfc2307' to be on by
> default, as if a value is specified in the directory, by the
> administrator, it seems pretty clear to me that we want to use it unless
> specifically disabled. 
> 
> If/when we do come up with better solutions, and if we want to ditch
> idmap.ldb, we can still import the idmap.ldb into the directory (as
> rfc2307 attributes with an extension such as the above). 

Indeed, and I would rather do it sooner than later.

> In short idmap is hard.  What we have for the 4.0 release isn't ideal,
> but I think we can release with it, and take our time to get any new
> solution right.   

The longer w delay the messier, but we have time constraints so it is
what it is.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>