algorithmic, IDMAP_BOTH and rfc2307 attributes for s4 id-mapping?
Andrew Bartlett
abartlet at samba.org
Mon Oct 15 18:33:38 MDT 2012
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
More information about the samba-technical
mailing list