Bug exists in Samba 3.0.25a-0.1.61 as well - wbinfo -g works, wbinfo -u works, getent group works, but getent passwd does not return any domain users.

This is not a bug it is a feature. Enumerating users and groups has been disabled in 3.0.24 by default cause it sometimes it doesn't work as expected. You can attend the discusssion at the Samba.org mailist list.

From the Samba WHATSNEW.txt

winbind enum users       Changed default  No
winbind enum groups      Changed default  No

You can turn these option on in the smb.conf file. Then 'getent passwd' should work again.

I do have winbind enum users and winbind enum groups set to on in smb.conf- hence getent group is working, and I am calling getent passwd's failure a bug :)

User enumeration in and of itself is of no big importance to me (may be to others) - however, I cannot setfacl or chown to AD users and I believe the bug preventing me from doing that is the same that is causing getent passwd to fail despite winbind enum users being set to yes.

Problem exists in the recently released samba-3.0.25a-8.1.63 version as well.

Looking at winbindd.log, the following shows up multiple times for each domain entity:

[2007/06/09 23:26:07, 1] nsswitch/winbindd_user.c:winbindd_getpwent(728)
  could not lookup domain user User1

However, doing a wbinfo --name-to-sid=User1 works fine, then a wbinfo --sid-to-uid for the Sid obtained for User1 works fine as well.

smb.conf contains the following entries pertaining to uid/gid <-> sid mapping:

        idmap domains                   = AD
        idmap config AD:backend         = rid
        idmap config AD:base_rid        = 1000
        idmap config AD:range           = 10000 - 20000

Created attachment 145892 [details]
Log with debug level 10 while doing wbinfo -u

Created attachment 145893 [details]
My smb.conf

erm... OK I think I attached these files to the wrong bug. I dont know how....

sorry guys.

I've currently updated winbind form 3.0.23d to 3.0.25a. After that I wasn't able to login and getent passwd didn't return any domain users. I had to restart nscd to get it working.

Please stop nscd and try. Then start nscd and try again.

Just an FYI, in my case, stopping, starting nscd has no effect on getent passwd not working.  Having verified that, I plan on keeping nscd stopped no the test box .

Please attach your smb.conf. I can't reproduce it here. It works just fine.

krikkit:~ # cat /etc/SuSE-release
openSUSE 10.2 (X86-64)
VERSION = 10.2
krikkit:~ # rpm -q samba-winbind
samba-winbind-3.0.25a-8.1.63
krikkit:~ # getent passwd "SBS-TEST\\anschneider"
SBS-TEST\anschneider:*:10000:10000:Andreas Schneider:/home/SBS-TEST/anschneider:/bin/bash

Created attachment 146421 [details]
My smb.conf

Here is my smb.conf.

I've used your config, disabled the password server and changed the domainname and netbios name. It works just fine for me.

krikkit:~ # wbinfo --sequence && getent passwd "anschneider"
BUILTIN : 1181895891
KRIKKIT : 1181895891
SBS-TEST : 389838
anschneider:*:10239:10000:Andreas Schneider:/home/SBS-TEST/anschneider:/bin/false

As mentioned before enumerating users and groups has been disabled in 3.0.24 by default cause *sometimes it doesn't work as expected*. So wbinfo -u should do the job.

Does everything else work? So can we close the bug?

I do not see how this bug can be left "as is".  It is not really getent passwd that I am worked up about, it is the fact that the user accounts from the domain that are not listed by getent passwd cannot be used to set ACLs, which, IMHO, is of critical use for most users of Samba.

The primary use of Samba on Linux, for myself and I am sure many others, is to replace Microsoft Windows member servers in a Windows domain.  I have done that with great success in many cases using Samba 3.0.23d-19.5.  Using ACLs and AD domain integration, I have replaced many Windows file servers with Linux machines.

Now, with this latest release of Samba, I cannot use setfacl or anything else that requires using domain accounts at the file system level (chown etc).  This makes the use of Samba on Linux as a file server replacement for MS Windows impossible, and I am sure one of the primary uses of Samba, together with it's AD integration, is on file servers.

Having said all that and hoping the bug will not be closed, here are some more observations.  Going through the source for winbind (nsswitch/winbindd_user.c to be exact), I notice that the GID for the user's "primary" group is looked up.  I re-did my tests for getent group.  I was wrong in saying that getent group works fine - it does not show the built-in domain users or domain admins groups.  Further, when if I go into dsa.msc (AD users and groups console) and set a group that does show up in the getent group output, then that user shows up in getent passwd.

So the problem is not one of getent passwd not showing certain users - that is an effect.  A more fundamental cause is certain built-in groups (I am only sure about domain admins and domain users so far - I am looking further) do not show up in getent group - and if those groups are the only, or the primary, groups for users, then those users fail to show up in getnet passwd output.

Trying to track why built in group domain users does not show up in getent group, I ran the following tests:

wbinfo --name-to-sid="domain users"
S-1-5-21-4075376926-2798723368-2832161110-513 Domain Group (2)
[root@suse-test:/var/log/samba]wbinfo --sid-to-gid=S-1-5-21-4075376926-2798723368-2832161110-513
Could not convert sid S-1-5-21-4075376926-2798723368-2832161110-513 to gid

So the problem is ~why~ is wbinfo --sid-to-gid using the well known RID for a built-in group failing?  That, at least IMHO, is the root cause of the problem.  I am going to trawl through the logs and see if I can find out anything else.  In the meantime, can you verify that the wbinfo tests above work for you using my (albeit modified for your environment) smb.conf?

Many thanks for sticking with this.

Ok, I think the problem is solved.  The culprit is the idmap config <domain>:base rid=1000 setting.  With this in place, no RIDs less than 1000 will ever get mapped to UIDs or GIDs.  This causes all the built-in default groups (including domain users) to not get mapped - that in turn causes a failure to enumerate any users that belong to these groups - and most users will belong to the domain users group.

Setting idmap config <domain> base rid = 0 fixes the issue and I see no ill-effects from it.  All the man pages seem to suggest that a value of 1000 for this setting is good, but that is what causes a failure to map to GIDs the SIDs of all built-in groups.

I would say the suggested, example configs listed in the docs should reflect this somehow, or this will cause quite a lot of grief for people who decide to use the idmap rid module.

Thanks for all your help.

This is a bug in 3.0.25. Simo is working on it.

Ok, to clear things and for the history.

3.0.23 does not support the 'idmap config MAIN:backend  = rid' this is just ignored.

All versions before 3.0.25 are use the following config options:

idmap uid = xxx-yyyy
idmap gid = xxx-yyyy

The default value for base_rid is 0

dmap config MAIN:backend  = rid
dmap config MAIN:base_rid  = 0

The manpage just says that base_rid = 1000 can be a good value.