idmap_ad group id mapping.

[Giuseppe Ragusa]

Hi all,

I think that the behaviour described by Nimrod would be really useful,
especially in large organizations with new users assigned to "Domain Users"
by default as primary group (Windows-side), POSIX attributes "granted" only
for a limited number of users/groups in an "experimental way" and no hope of
getting the gidNumber POSIX attribute into such a fundamental Windows group
as "Domain Users" by the powers that be.

I think that a similar reasoning was already explained on this list before and
it is my understanding that the described behaviour was the default in Samba
releases < 3.5.0:

https://bugzilla.samba.org/show_bug.cgi?id=8694

https://bugzilla.samba.org/show_bug.cgi?id=7582

https://bugzilla.samba.org/show_bug.cgi?id=8905

I agree that, apart from primary group, membership in other groups
should be governed by the "Windows-side" membership logic (since I recall from
the aforementioned list discussions and other Samba doc sources that the "pure"
RFC2307bis group membership mechanisms are ill-implemented in AD and generally
not a viable solution): it seems sensible that groups that are vital "UNIX-side"
(mainly for filesystem ACEs/ownership or similar authorization reasons) should
have their gidNumber set in AD.

To be clear I'm thinking of an additional parameter like:

idmap config DOMAINNAME : primary_group_mode = rfc2307

vs.

idmap config DOMAINNAME : primary_group_mode = ad

with the latter being the default if not specified (for continuity with the
latest versions of Samba). I suppose that "sfu" instead of "rfc2307" could be
used by those using the corresponding schema_mode.

I have a use case exactly like this and would like to contribute to the
development of such a patch, even if my previous coding/inspecting attempts
(by means of comparing Samba sources for idmap_ad pre and post 3.5.0) failed
miserably; I would dare to suggest that such a patch would be useful even
for the still maintained branches of 3.5.x and 3.6.x, once established in master
(I for one use CentOS 6 and cannot use SSSD nor FreeIPA for the purpose of AD
integration: submitting the patch to RedHat as an RFE for Samba 3.5.x would
arguably be easier/require the patch accepted upstream).

Many thanks,
Giuseppe

Nimrod Sapir <NIMRODS at il.ibm.com> wrote on Wed Aug 1 09:59:59 MDT 2012:

> Hi Adam
>
> I'm not sure I understand all your comments below. It still seems to me 
> that for a customer using SFU for ID mapping, the consistent and intuitive 
> way to determine the GID for a AD account which has UID in the schema is 
> the Primary group name/GID entry. When looking at the UNIX attributes tab 
> it is very obvious that this field is meant by Microsoft to be used as the 
> matching GID for the UID. Also, the way it is defined enforces the user to 
> provide GID to every UID, either by choosing a group which has GID, or by 
> adding it manually to the schema. 
>
> Yesterday, I dived into the code trying to understand how this patch can 
> be done. The fix doesn't seem to be trivial at all, as the flow that leads 
> from the first AD query of the user to the SID->GID resolution in AD is 
> quite complicated. I added some hacks to winbind_ads.c and idmap_ad.c, but 
> with partial success. adding the "winbind nss info = rfc2307" did change 
> the flow a bit, but eventually the smbd process runs using the gid of the 
> primary group rather than the gid written in the Primary group name/GID 
> field. 
>
> Do you think that the change described is of interest to the community? Do 
> you have any suggestion regarding the easiest way to change the flow to 
> match this behavior?
>
> Thanks
> Nimrod
>
>
>
> Michael Adam <obnox at samba.org> wrote on 12/07/2012 17:48:42:
>
> > From: Michael Adam <obnox at samba.org>
> > To: Nimrod Sapir/Israel/IBM at IBMIL, 
> > Cc: Dan Cohen1/Israel/IBM at IBMIL, Lior Chen/Israel/IBM at IBMIL, samba-
> > technical <samba-technical at lists.samba.org>
> > Date: 12/07/2012 17:48
> > Subject: Re: idmap_ad group id mapping.
> > 
> > Nimrod Sapir wrote:
> > > Michael Adam <obnox at samba.org> wrote on 12/07/2012 01:20:57:
> > > > 
> > > > Yes, this is actually how it should work:
> > > > Samba takes the windows user token and turns it into
> > > > a unix token. Here the expected thing is to turn the windows
> > > > groups into unix groups (by id mapping) one-to-one.
> > > > 
> > > > I would say that the windows admins should give the
> > > > user a primary (windows) group that also carries a gidnumber
> > > > unix attribute. I can't see why a windows admin would give
> > > > the user a primary windows group (maybe w/o gid number) and
> > > > primary gid number in the unix attributes that refers to a
> > > > different windows group or to no windows group at all.
> > > > 
> > > > But it seems to be a rather frequent request.
> > > > If it is really important, then we could make it configurable
> > > > to let samba choose the primary gid from the windows user
> > > > sfu attributes as the unix primary gid.
> > > 
> > > I would say that the existing behavior is reasonable (as well as expecting 
> > > the user to enforce the gid value of the primary group) if the "primary 
> > > group name/GID" field was not there, right below the UID field. I, as a 
> > > user, was sure that this field would determine the GID. I believe this is 
> > > also what Microsoft expect from systems which are using this scheme 
> > > (otherwise, why is it there?),
> > 
> > Well, I think the primary use of this is Unix/NFS interaction.
> > Also, from Windows 2003R2 on, the schema extensions are part of
> > the so called "services for NFS"...
> > 
> > http://technet.microsoft.com/en-us/library/cc782783%28v=ws.10%29
> > http://technet.microsoft.com/en-us/library/cc753302%28v=ws.10%29.aspx
> > 
> > This is meant for systems that unlike samba/winbindd don't do
> > an id mapping of the windows SIDs themselves.
> > 
> > > and from the perspective of a customer which has large Active
> > > Directory, and want to allocate different GID to different
> > > users, the existing behavior is error-prone while the second
> > > approach ensures consistency.
> > 
> > The point is that the samba server is more on the windows side
> > than on the unix side, from the windows clients' point of view.
> > So we should by default map the windows world to the unix world
> > as 1:1 as possible. We can optionally add in the primary gid
> > from the unix attributes in the idmap_ad scenario. But what
> > relevance would the primary windows group have, if it is also
> > mapped to a GID?
> > 
> > Difficult.
> > 
> > There is by the way already a mechanism for choosing the
> > gid from idmap_ad: you need to configure the nss_info
> > correspondingly. Set
> > 
> > "winbind nss info = sfu"
> > 
> > in addition to your idmap config (or = rfc2307, you have to check).
> > Please read the "smb.conf" manpage for more background.
> > 
> > Cheers - Michael
> > 
> > 
> > [attachment "atti45z3.dat" deleted by Nimrod Sapir/Israel/IBM]