idmap_ad group id mapping.

[Giuseppe Ragusa]

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]