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

[Andrew Bartlett]

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.

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.

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.  

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.

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

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.   

Thanks,

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