idmap_ad group id mapping.

Wed Aug 8 07:15:25 MDT 2012

Hi Giuseppe

I dived into the code myself before writing my previous post. While I 
found a flow in winbind_ads.c which does a query on the primary group for 
getting the gid (and can maybe be replaced with querying for the direct 
gid entry), it seems that this flow is a secondary flow. The main flow, if 
I understand correctly, revolves around the caching kept in the 
netsamlogon_cache.tdb. I believe that each time a user connects to the 
server, Samba gets the entire user information and keeps it in the 
netsamlogon_cache.tdb file. This is where, in most flows, the primary 
group info comes from. Actually, Samba does not need to query the primary 
group directly, since the primary group is always the first group in the 
list of groups. Since this information is distributed across a large 
number of data structures and flows, the fix becomes non-trivial. Also, 
the primary group and primary group/gid are not in the same format - 
primary group is a SID, while primary group/gid may contain a GID which is 
not mapped to any AD group. Of course, the primary group/gid is not always 
available, so the system needs to verify it's existence (and the ID 
mapping schema in use) before using this entry rather than the primary 
group entry.

Of course, my understanding is very partial and based on a few hours of 
code review without any previous understanding of the above mechanisms. I 
would appreciate a feedback on what I just said

Thanks.
Nimrod Sapir
IBM - XIV, Israel
NAS Development Team
Office: +972-3-689-7763
Cell:   +972-54-7726-320

samba-technical-bounces at lists.samba.org wrote on 08/08/2012 12:25:18:

> From: Giuseppe Ragusa <giuseppe.ragusa at hotmail.com>
> To: "samba-technical at lists.samba.org" <samba-technical at lists.samba.org>, 

> Date: 08/08/2012 12:25
> Subject: idmap_ad group id mapping.
> Sent by: samba-technical-bounces at lists.samba.org
> 
> 
> Sorry for replying to myself:
> I tried (again) to compare latest Samba sources (from beta5) to 3.4.
> 17 in the source3/winbindd subdir but I was not able to find the 
> right spot to start working on a patch (btw: was the suggested 
> parameter/logic sound?).
> Even looking directly into the winbind_ad.c and idmap_ad.c files (as
> suggested by Nimrod) I do not seem to find where the current logic 
> (take uidNumber from user and extract gidNumber from Windows-side 
> primary group - if not found, "give up" on user) resides.
> I think I understand the main abstraction layers (the _backends_ 
> functions and their backend-specific counterparts), but somewhere 
> around the pull_uint32 and _cached_ function calls I got lost.
> Could anyone knowing the implementation suggest me where to start 
> from (or relevant docs to read)?
> Many thanks again,Giuseppe
> > 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] 
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1338 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120808/e2abd030/attachment.gif>