Bug 3530 - Winbind dropping other-domain users from domain local groups on Win2K3 ADS
Winbind dropping other-domain users from domain local groups on Win2K3 ADS
Status: REOPENED
Product: Samba 3.0
Classification: Unclassified
Component: winbind
3.0.21b
x86 Linux
: P3 enhancement
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
: 3826 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-20 12:33 UTC by D.L. Meyer
Modified: 2014-09-26 09:24 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 D.L. Meyer 2006-02-20 12:33:33 UTC
"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
--------------------------------------------------------------------------------------------
Comment 1 Volker Lendecke 2006-02-20 13:16:51 UTC
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
Comment 2 D.L. Meyer 2006-02-20 14:51:19 UTC
(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...
Comment 3 Volker Lendecke 2006-02-20 15:19:59 UTC
> 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
Comment 4 Björn Jacke 2014-07-23 21:46:58 UTC
*** Bug 3826 has been marked as a duplicate of this bug. ***