[PATCHES RESEND] idmap_rfc2307 module

[Christof Schmitt]

Andrew Bartlett <abartlet at samba.org> wrote on 08/29/2012 02:41:58 PM:
> On Fri, 2012-08-24 at 10:37 -0700, Christof Schmitt wrote:
> > > Why do you need the different suffixes, rather than just using the
> > > common base and a search filter?
> > 
> > We have seen directories where there are different records for the
> > same user or the same group in different parts of the LDAP
> > hierarchie. Using different suffixes for users and groups allows us to
> > point to the specific records to query.
> 
> That's weird.  The reason I'm so picky about this is that as we try and
> more closely emulate a NTFS file server, the distinction between a user
> and a group breaks down.  Groups can own files, and users can become
> groups when they become entries in a sidHistory.
> 
> I've started to find this very pain myself as I work on migrating
> 'classic' samba domains into Samba4, as we need 'domain admins' to own
> some group policy object.
> 
> That's why I'm nervous about further embedding a split between users and
> groups.  For example, it would be great to be able to map a SID to the
> user-private group (RH style) if we needed to. 
> 
> Now, a real-world site trumps theoretical objections, and this module
> has a specialist role in an environment that is more strictly user/group
> delineated, but I wanted to explain my reasoning so you could see if
> there is any other way you could avoid embedding such a delineation
> while finding only the 'right' users. 

The LDAP directory we have to support can have the same mappings in
different parts of the trees. The distinction between users and groups
allows to be specific to which part of the tree the records should be
picked from.

Another idea would be to query the records, and if there is more than
record, find the one with the longest dn. That is the one that should
usually be preferred. But then there could also be records in
different branches, so we would need to add a config to prefer one
branch over another. Given those complications, implementing the
distinction between users and groups seems like a better approach for
this data.

Regards,

Christof Schmitt || IBM || SONAS System Development || Tucson, AZ
christof.schmitt at us.ibm.com  ||  +1-520-799-2469  (T/L: 321-2469)