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

[Andrew Bartlett]

On Mon, 2012-10-15 at 20:20 -0400, simo wrote:
> 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.

Thanks.  My hope is that we can make it optional, for administrators
that need to specifically assign uid/gid values for AD groups that need
to own files.  (Otherwise, they can live with the restrictions). 

> > 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.

Sure, but what I mean is that at some point the next trusted domain (in
a forest) needs to start.  The URL above is not clear what the gap
between domains is. 

> > 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.

I was more thinking about clashes with uid values in the system passwd
DB on a server hosting or (via winbindd and an idmap module that reads
these values) being a member of a Samba4 domain.  If we choose to use
this however, we can just document this limitation.

> > 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.

I agree.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org