I see that when I do "getent passwd", I get an entry like this: testuser:*:1000:20:Test User:/home/poo/testuser:/bin/bash But when I do "getent passwd testuser", I get this: testuser:*:1000:100:Test User:/home/poo/testuser:/bin/bash It seems that when doing getent passwd username, the primary group is the user's gidNumber attribute in active directory (which is correct). However when doing getent passwd to retrieve a full list of users, it uses the windows primary group (set via primaryGroupID) instead. This is bad since it's inconsistent, but also bad in our environment since Domain Users doesn't have a gidNumber setup. This means any user with the windows primary group set as the default doesn't come up when doing a "getent passwd". In active directory, for each UNIX user the uidNumber, gidNumber, and loginShell attributes are set. The groups that are used in UNIX have gidNumber set. The home directory attribute is not set, since that is different per platform (the MACs use /Users instead of /home, and I wanted each platform to use their own default). Below is my smb.conf: [global] log level = 3 log file = /var/log/samba/smbd.log security = ads workgroup = EXAMPLE realm = EXAMPLE.COM server signing = auto allow trusted domains = no winbind use default domain = yes winbind enum users = Yes winbind enum groups = Yes winbind nested groups = Yes template shell = /bin/sh template homedir = /home/poo/%U winbind nss info = rfc2307 idmap backend = ad
Hmm, I thought that when using idmap backend = ad, the windows primary group should have a GID attribute and this should be used as primary unix group. I am going to investigate this.
(In reply to comment #1) > Hmm, I thought that when using idmap backend = ad, > the windows primary group should have a GID attribute > and this should be used as primary unix group. > > I am going to investigate this. The gidNumber attribute for the primary group is only used if you have "winbind nss info" enabled.
I have confirmed this same issue with 3.3.0. I've also done testing with removing the "winbind nss info" config option, in which case "getent passwd" and "getent passwd username" both return consistent values. So it would appear that whatever conditional is used to differentiate which attribute to use just needs to be applied to the function that handles "getent passwd", just like it is when doing "getent passwd username".
Ok, I have investigated the code and confirmed the bug. The special special treatment of primary gid retrieved via nss info is only there for the getpwnam call ("getent passwd <username>"), _not_ for the gepwent call ("getent passwd"). I am going to work on a fix. But I will really have to wrap my mind around this, if it is possible to fix this in a simple way at all: The problem here is that the getpwent function is not using the async mechanisms for sid2gid mapping, and hence the nss_info layer does not automatically enter the scene... Cheers - Michael
Coming back to this after a really long time... The change to be able to properly do the enumeration ("getent passwd") is big. It won't go into any of 3.2, 3.3, 3.4. But Winbind has been restructured in master/3.5 by Volker to make such changes possible. I think this will be gone in 3.5, but I have to verify. Cheers - Michael
We have unified the code paths in 4.6. Please retry.