Hello, 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. Sincerly, Klaus
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?
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: https://bugzilla.samba.org/show_bug.cgi?id=3165 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.
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.
(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! Sincerly, Klaus
c3057f69a274f0d8e0e66183bd5e8be7703b6750 *** This bug has been marked as a duplicate of bug 9880 ***