Bug 6059 - "getent passwd"/"getent passwd username" inconsistencies
"getent passwd"/"getent passwd username" inconsistencies
Status: ASSIGNED
Product: Samba 3.2
Classification: Unclassified
Component: Winbind
3.2.7
x86 Linux
: P3 normal
: ---
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-20 18:50 UTC by Nick (550-5.1.1 The email account that you tried to reach does not exist)
Modified: 2009-11-20 18:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick (550-5.1.1 The email account that you tried to reach does not exist) 2009-01-20 18:50:06 UTC
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
Comment 1 Michael Adam 2009-01-28 05:46:54 UTC
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.
Comment 2 Gerald (Jerry) Carter 2009-01-28 08:10:51 UTC
(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.
Comment 3 Nick (550-5.1.1 The email account that you tried to reach does not exist) 2009-02-01 13:10:20 UTC
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".
Comment 4 Michael Adam 2009-02-02 03:46:33 UTC
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
Comment 5 Michael Adam 2009-11-20 18:56:42 UTC
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