Bug 9880 - Use of wrong RFC2307 primary group field.
Summary: Use of wrong RFC2307 primary group field.
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Winbind (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
: 7582 8694 9751 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-05-13 20:28 UTC by Nathan Frankish
Modified: 2014-07-24 19:19 UTC (History)
4 users (show)

See Also:


Attachments
screen shot one - Unixattributes tab (76.06 KB, image/jpeg)
2013-05-13 20:28 UTC, Nathan Frankish
no flags Details
screen shot 2 (81.65 KB, image/jpeg)
2013-05-13 20:29 UTC, Nathan Frankish
no flags Details
patch to document the requirement of uid/gidNumber attributes and more verbose log output (2.42 KB, patch)
2013-05-17 16:40 UTC, Björn Jacke
no flags Details
patch for 4.0 with documentation update and enhanced log output for missing mappings (2.56 KB, patch)
2013-05-17 16:45 UTC, Björn Jacke
metze: review+
Details
Back port for 3.6 - differing man page path (2.68 KB, patch)
2013-06-18 16:20 UTC, David Disseldorp
bjacke: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Frankish 2013-05-13 20:28:55 UTC
Created attachment 8881 [details]
screen shot one -  Unixattributes tab

Ive spent the last week working out why my samba installation would work with Samba3.3.8 but not with anything in the 3.5, or 3.6 range.

My environment is redhat 5.5 and 6.4 in an Windows Active Directory 2008R2 environment. We use RFC2307 for unix attributes set at AD level.

I was getting random errors such as
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND when running wbinfo -i username

getent password would simply return nothing. getent group would work

After much troubleshooting and debuging, i have worked out the following.

Somewhere along the lines winbind stopped using the primary group field as listed in the Unix Attributes tab (screenshot1.jpg)
and started using the primary group tab in the member of section (See screenshot2.jpg). 

I cant seem to find any documentation outlining this change or why this change of functionality happened.

The root casue for me, was that my domain users group, as listed in the member of tab, didnt have unix attributes on it, as it never needed them before due to the primary group being taken from the group listed in the unixattributes tab always being primary.

Can anyone tell me why this changed?> or how to change it back?
Comment 1 Nathan Frankish 2013-05-13 20:29:16 UTC
Created attachment 8882 [details]
screen shot 2
Comment 2 Björn Jacke 2013-05-14 05:21:31 UTC
the idmap_ad man page says: "This module implements only the "idmap" API, and is READONLY." which kind of documents it. There might be reasons why people might want to have a different primary group but havin consistence with the group memberships is more important for most people. Group memberships are still not completely consistent because the lack of gidNumber attribute of member groups would also make the groups disappear from user membership groups. I agree that the man page of idmap_ad might need some more information and also we might add some more debug messages when we encounter user groups which don't have a gidNumber attribute because this might actually cause not so obvious trouble.
Comment 3 Björn Jacke 2013-05-17 16:35:10 UTC
*** Bug 8694 has been marked as a duplicate of this bug. ***
Comment 4 Björn Jacke 2013-05-17 16:40:24 UTC
Created attachment 8904 [details]
patch to document the requirement of uid/gidNumber attributes and more verbose log output
Comment 5 Björn Jacke 2013-05-17 16:45:08 UTC
Created attachment 8905 [details]
patch for 4.0 with documentation update and enhanced log output for missing mappings
Comment 6 Karolin Seeger 2013-05-27 11:56:44 UTC
Pushed to autobuild-v4-0-test.
Comment 7 Karolin Seeger 2013-05-29 09:43:05 UTC
Pushed to v4-0-test.

Björn, is this neede for 3.6, also?
Comment 8 Björn Jacke 2013-05-31 20:02:20 UTC
as this is not critical i think 4.0 is enough. Thanks!
Comment 9 David Disseldorp 2013-06-18 16:17:27 UTC
Reopening for 3.6 merge, the documentation update is particularly useful. Patch to follow...
Comment 10 David Disseldorp 2013-06-18 16:20:19 UTC
Created attachment 8980 [details]
Back port for 3.6 - differing man page path
Comment 11 Björn Jacke 2013-06-19 06:35:38 UTC
Comment on attachment 8980 [details]
Back port for 3.6 - differing man page path

lgtm
Comment 12 David Disseldorp 2013-06-19 08:35:39 UTC
(In reply to comment #11)
> Comment on attachment 8980 [details]
> Back port for 3.6 - differing man page path
> 
> lgtm

Thanks.

@Karolin, please put this on the queue for 3.6.next.
Comment 13 Karolin Seeger 2013-06-19 08:57:06 UTC
Pushed to v3-6-test.
Closing out bug report.

Thanks!
Comment 14 Björn Jacke 2014-07-23 16:57:30 UTC
*** Bug 7582 has been marked as a duplicate of this bug. ***
Comment 15 Björn Jacke 2014-07-23 21:51:20 UTC
*** Bug 9751 has been marked as a duplicate of this bug. ***
Comment 16 Björn Jacke 2014-07-24 19:19:09 UTC
*** Bug 7582 has been marked as a duplicate of this bug. ***