"Domain local group" members from other trusted domains are not showing up in group lists as enumerated via winbind. Yet group members from the same domain as the domain local group are enumerated/listed properly. In a rather complex ADS arrangement (described below), I have several RHEL4 systems with Samba/Winbind installed and configured. Everything appears to be working properly thus far: users & groups from the default domain are properly enumerated and resource permissions are mapping correctly. Users and groups from other 2-way trusted domains are also enumerated. (This was evaluated with "wbinfo -u|g" & "getent passwd|group".) The domain structure & relationships are a bit hairy though, and need to be spelled out: Three independent ADS domains in separate forests: "ACES" realm: COLLEGE.ACESNET.UIUC.EDU "EXTENSION" realm: EXTENSION.UIUC.EDU "ACES" & "EXTENSION" have an established 2-way trust. The RHEL4 systems are member servers in domain "ACES". This is tested under Samba versions 3.0.10-1.4E2 & 3.0.21b-3. I can see groups from domain "EXTENSION" just fine in the output, and their membership of users from domain "EXTENSION" -- these should be the global|universal groups from domain "EXTENSION". Also, both "ACES\gfleegman" and "EXTENSION\j-bogus" show up properly in output from: wbinfo -u getent passwd The PROBLEM: There are domain local groups defined in "ACES" that have members from these other domains. (E.g. domain local group "ACES\webadlocaltest" is defined on the Win2K3 DCs as consisting of two users: "ACES\gfleegman" and "EXTENSION\j-bogus".) On the linux systems, the command: getent group shows a group membership for "ACES\webadlocaltest" of only one user: "ACES\gfleegman". Now, when I run the command: net rpc group members webadlocaltest -S college.acesnet.uiuc.edu -U ACES\\admin%passwd I receive the full and proper list of users: ACES\gfleegman EXTENSION\j-bogus Furthermore, testing user account group membership: net ads user info gfleegman -S college.acesnet.uiuc.edu -U admin%passwd yields the single response: "webadlocaltest" net ads user info ACES\\gfleegman -S college.acesnet.uiuc.edu -U admin%passwd yields an empty list. net ads user info EXTENSION\\j-bogus -S college.acesnet.uiuc.edu -U admin%passwd yields an empty list. Now, to get more interesting: net rpc user info gfleegman -S college.acesnet.uiuc.edu -U admin%passwd yields the more complete response: "webadlocaltest" "Domain Users" (**NOTE the difference between "ads" & "rpc" methods...**) As above with ads, both of the following commands: net rpc user info ACES\\gfleegman -S college.acesnet.uiuc.edu -U admin%passwd net rpc user info EXTENSION\\j-bogus -S college.acesnet.uiuc.edu -U admin%passwd ... still yield an empty list. When I test group membership from a Windows-based member server, we get the proper list of both "ACES\gfleegman" & "EXTENSION\j-bogus". I have tested these scenarios under both versions of Samba mentioned above, as well as with the option "winbind use default domain" both yes & no. I've tested independently with the "winbind separator" set to "\\", "/" and "+". Results were identical under all variations tested. My suspicion is that winbind is somehow limiting its enumeration of group membership to users from the same domain to which the group belongs. I believe this to be incorrect behavior, given that a windows server reports the full list, and that at least one command within Samba can properly obtain the full list from the W2K3 DCs. (That said, I remain open to the thought that it might be a misconfiguration on my part - despite the apparent normal operation of all other aspects on the linux/samba system.) smb.conf (testparm output) follows: -------------------------------------------------------------------------------------------- [global] workgroup = ACES realm = COLLEGE.ACESNET.UIUC.EDU netbios name = X-ACES-LBE-2 server string = %L (Samba v%v) security = ADS password server = college.acesnet.uiuc.edu username map = /etc/samba/smbusers log file = /var/log/samba/%m.log max log size = 50 name resolve order = host lmhosts wins bcast deadtime = 15 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 local master = No dns proxy = No wins server = 128.###.#.#0, 128.###.#.#1 idmap uid = 10000-100000000 idmap gid = 10000-100000000 template homedir = /home/gaol winbind separator = \\ winbind cache time = 10 hosts allow = 127., 128.###.###.0/255.255.254.0, 128.###.###.0/255.255.254.0, 130.###., 128.###.##., 192.168.###. case sensitive = No # include = /etc/samba/smb.conf.lbe-2 [dev-W] path = /export/dev/W valid users = "@ITCS CSS Team", "@Domain Admins", IUSR_ACESWEB admin users = "@Domain Admins" read only = No create mask = 0664 directory mask = 02770 inherit permissions = Yes veto oplock files = /*.TTF/*.XLS/*.DOC/ [prod-W] path = /export/prod/W valid users = "@ITCS CSS Team", "@Domain Admins", IUSR_ACESWEB admin users = "@Domain Admins" read only = No create mask = 0664 directory mask = 02770 inherit permissions = Yes veto oplock files = /*.TTF/*.XLS/*.DOC/ [tmp] comment = Temporary file space path = /tmp valid users = "@ITCS CSS Team", "@Domain Admins" admin users = "@Domain Admins" read only = No create mask = 0664 directory mask = 02770 dos filetime resolution = Yes --------------------------------------------------------------------------------------------
I hate to reject bugs with WONTFIX, but I think this can not be fully done. Querying remote group members can never be listed with any reliability these days. We will try to slowly improve on that one, but it is a battle we already lost. Windows just does not allow querying the user database if not coming in as administrator. Please note that in your net command samples you did specify "admin" as login user. The _only_ operation that winbind can reliably do is get the list of groups a user is in given that the user has logged in. Anything else is bound to fail in some scenarios. Volker
(In reply to comment #1) Volker, I ask you to reconsider, for the following reasons: 1) In rebuttal to your statement "Windows just does not allow querying the user database if not coming in as administrator." -- while I may have specified that I used "-U admin%password", it is trivial to verify that "-U ordinary_user%password" results in the very same positive result from "net rpc group members {groupname} ..." Thus, the requirement is not an administrative user, but any valid user on the domain. Since we are dealing with the home domain for the server(s), it is imperative that domain local group membership lists are properly and completely expanded. Especially if the trust conditions allow the successful listing of the trusted-domain/users and the trusted-domain/groups on the samba server(s), to arbitrarily exclude trusted-domain/users from local-domain/groups is a glaring shortfall in function. 2) With the command "wbinfo --set-auth-user=...", one can set the user credentials necessary to view the information for the local domain, if needed. The problem is, there is something in winbind's group list enumeration logic that is dropping/filtering the trusted-domain users, where the "net" command does not drop /filter them. They should at least be consistent. (And crippling "net" in order to achieve consistency would be a step backwards, correct? So can we please look into having winbind behave as "net" can?) As for your last paragraph, are you implying that something should not be done simply because there are scenarios in which it might fail? This sounds "defeatist" -- Can't we at least make it work correctly for those (majority) scenarios where it can succeed? I understand the difficulties of working with one-way trusts -- I am impacted by that as well. This should at least work correctly for two-way trusted domains, where the user from the trusted domain(s) is(are) already successfully enumerated. Please do not close this without looking more closely. Volker, I get the sense you may not be completely understanding the situation -- if you have questions about the situation/circumstances that I might be able to clear up, please ask away...
> I ask you to reconsider, for the following reasons: As I said, this is something that we will work on as time allows, but it is very difficult to implement and later on debug a feature that might or might not work depending on which domain controller you happen to be connected. Yes, some of the security settings have changed with Service packs of Windows 2003. > 1) In rebuttal to your statement "Windows just does not allow querying the user > database if not coming in as administrator." -- while I may have specified that > I used "-U admin%password", it is trivial to verify that "-U > ordinary_user%password" results in the very same positive result from "net rpc > group members {groupname} ..." Thus, the requirement is not an administrative > user, but any valid user on the domain. I have tried other queries, in particular --user-sids. This really only works if you are authenticated as the user who asks for the information or as the domain administrator, at least with the version of Windows 2003 I have. This is not a functional problem that we do not issue the right calls, it is the ACL settings on the Active Directory. > Since we are dealing with the home domain for the server(s), it is imperative > that domain local group membership lists are properly and completely expanded. > Especially if the trust conditions allow the successful listing of the > trusted-domain/users and the trusted-domain/groups on the samba server(s), to > arbitrarily exclude trusted-domain/users from local-domain/groups is a glaring > shortfall in function. If domain local groups are not expanded for users just logging in, this is indeed a bug. It is not a bug if you don't see the correct group memberships with any "remote" tool, not providing the user's credential. And this is what you seem to do. > 2) With the command "wbinfo --set-auth-user=...", one can set the user > credentials necessary to view the information for the local domain, if needed. > The problem is, there is something in winbind's group list enumeration logic > that is dropping/filtering the trusted-domain users, where the "net" command > does not drop /filter them. Might be true. But again, I would consider this to be a pure feature enhancement. > As for your last paragraph, are you implying that something should not be done > simply because there are scenarios in which it might fail? This sounds > "defeatist" -- Can't we at least make it work correctly for those (majority) > scenarios where it can succeed? It is microsofts tendency to close down security as much as possible. If we were still in a pure NT4 environment, things would be different. But with every service release they close down holes. > Please do not close this without looking more closely. Volker, I get the > sense you may not be completely understanding the situation -- if you have > questions about the situation/circumstances that I might be able to clear up, > please ask away... I might not know 100% of your particular situation, but I do know that we have known holes in enumerating groups and group memberships. We can leave this open, but only as a feature enhancement. Again: If you have a case where a user who just logged on via smbd or pam_winbind does not get its correct groups, then it _is_ a bug, but I did not see that from your report. When you have such a case, I might warn you that we have done a lot of work in current 3_0, so we will ask you to reproduce it with current SVN code. Volker
*** Bug 3826 has been marked as a duplicate of this bug. ***