Bug 8694 - idmap_ad maps gidnumber of primary group instead of gidnumber attribute
Summary: idmap_ad maps gidnumber of primary group instead of gidnumber attribute
Status: RESOLVED DUPLICATE of bug 9880
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.5.10
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
Depends on:
Reported: 2012-01-10 12:00 UTC by Klaus Steinberger
Modified: 2013-05-17 16:35 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Steinberger 2012-01-10 12:00:42 UTC

this problem struggles me since a while.  Since 3.5.0 something changed badly inside idmap_ad. In our environment users usually have a group "campus-user" with gidnumber 10000.  The synchronisation to Active Directory from our Novell Edirectory writes the RFC2307 attributes into Active Directory, but normally a user is added to "Domain Users" as his primary group.  "Domain Users" has no gidnumber attribute (and don't need it).

There is now the following behavior:

a user with "Domain Users" as his primary AD group:
      -   will not be mapped by idmap_ad

a user with "campus-user" as his primary AD group:
      -  will be mapped by idmap_ad with the correct gidnumber

a user with gidnumber 10000 but some other group (with a gidnumber attribut) as his primary group:
      - will be mapped by idmap_ad but with the incorrect gidnumber of the other group!

This looks like the RFC2307 gidnumber Attribute in the user object is not respected and would be overwritten by the gidnumber Attribute of the primary group. This leds to a failure of mapping if the group does not have a gidnumber attribute.

My tests with samba 3.6 show that the problem exists in 3.6 too.

Comment 1 Björn Jacke 2012-10-02 17:56:10 UTC
Michael: is this intended bahaviour? If yes, shouldn't we have clear log file warnings for this in a low log level and write about this behaviour it in the man page?
Comment 2 Colin.Simpson 2012-10-04 12:50:18 UTC
I think making the users primary group the windows primary for Unix is a sensible idea without any Unix attributes in AD to obey. But it makes no sense against the RFC2307 standard IMHO.

Ignoring the users gidnumber had me confused for ages as to why why Unix enabled users were being ignored by Winbind, when a commercial AD Linux solution saw them fine. It wasn't immediately obvious that I needed to add the gidnumber to Domain Users (my users default group), didn't see it in the docs. 

Doping this also means that migrating to AD is harder, as usually existing Unix primary groups already exist and changing the Windows side primary group maybe undesirable. Should at least be a config option?

I guess if this is change was made care it would be required to enumerate the Windows Primary group again on the Windows size, as discussed in this bug as to why it doesn't happen:


Though to be honest commercial AD solutions I've used always enumerate the Unix users primary group with users (even though not standard or required) without ill effects (I don't think this hurts anything) and is maybe slightly more consistent with Windows, at some level.
Comment 3 darrin 2012-10-22 13:48:10 UTC
Samba 3.5.10-125.el6 on RHEL6.3 suffers from this same bug.

wbinfo worked for everything except wbinfo -i username

The solution was to provide an NIS domain and UNIX GID (in the UNIX tab of the Active Directory console) for the user's Primary Group. The primary group for our configuration happened to be Domain Users. Once Domain Users had a GID, "wbinfo -i username" worked as expected.
Comment 4 Klaus Steinberger 2012-10-22 13:54:00 UTC
(In reply to comment #3)

> our configuration happened to be Domain Users. Once Domain Users had a GID,
> "wbinfo -i username" worked as expected.

Not as expected! It returns the gidnumber of the primary group instead of the gidnumber value of the user object!

Comment 5 Björn Jacke 2013-05-17 16:35:10 UTC

*** This bug has been marked as a duplicate of bug 9880 ***