Nesting of local groups (SID_NAME_ALIAS)
rpenny at samba.org
Fri Mar 17 16:56:08 UTC 2023
On 17/03/2023 15:37, Pavel Filipenský via samba-technical wrote:
> On 3/16/23 20:47, Rowland Penny via samba-technical wrote:
>> On 16/03/2023 19:20, Pavel Filipenský via samba-technical wrote:
>>> windbind does not correctly display members for e.g. BUILTIN/users.
>>> It shows nothing:
>>> ./bin/wbinfo --group-info BUILTIN/users
>>> Given that "BUILTIN\Users" has 1 member "ADDOMAIN\Domain Users", it
>>> should instead show:
>>> ./bin/wbinfo --group-info "ADDOMAIN/domain users"
>>> users:x:100006:ADDOMAIN/joe,ADDOMAIN/jane,ADDOMAIN/samba2008r2$,ADDOMAIN/samba2003$,ADDOMAIN/administrator,ADDOMAIN/krbtgt,ADDOMAIN/testallowed account,ADDOMAIN/testupnspn,ADDOMAIN/testdenied,ADDOMAIN/alice,ADDOMAIN/srv_account,ADDOMAIN/bob
>>> I am working on the fix. One part is to call
>>> dcerpc_samr_GetMembersInAlias() instead of the wrong
>>> dcerpc_samr_GetAliasMembership() in source3/winbindd/winbindd_rpc.c.
>>> Another part is to change the code dealing with nested groups /
>>> aliases. For that, I need to understand if aliases (SID_NAME_ALIAS)
>>> can be nested, like groups (SID_NAME_DOM_GRP).
>>> Reading the Microsoft documentation
>>> /A local group can contain user accounts that are local to the
>>> computer and user accounts and global groups from their own domain./
>>> It looks that "Local groups" which I believe is BUILTIN/users
>>> (SID_NAME_ALIAS) cannot contain another "Local group". I have tested
>>> that also on Windows server using lusrmgr.msc and such nesting was
>>> not possible.
>>> However, samba server allows such nesting:
>>> bin/net sam createlocalgroup TestGroup1
>>> bin/net sam createlocalgroup TestGroup2
>>> bin/net sam addmem TestGroup1 TestGroup2
>>> Can I assume that SID_NAME_ALIAS cannot be nested?
>>> Best regards,
>> My understanding of the BUILTIN groups is that they do contain 'local
>> groups', but that is 'local' to the domain, not the computer, or have
>> I misunderstood something.
>> There is also the point that I have never used BUILTIN\users and never
>> missed it.
>> What is your use case for this ?||
> The story started with fixing getgrouplist(3) in nss_wrapper. The next
> step is to bring the new version to samba (third_party: Update
> nss_wrapper to version 1.1.15) . But with the new nss_wrapper existing
> tests (smbtorture local.nss.membership) are failing. When analyzing the
> test failures, we have found bugs in samba code. One of them is here:
> dcerpc_samr_GetAliasMembership() is wrong, should be
> There is some more work needed (already in progress and somehow working)
> to make the alias membership to work correctly. The question is, if we
> should completely fix the alias functionality (given it is not needed in
> a real scenario) or if we should only change the tests.
If there is a bug, it definitely needs fixing, but in a way that suits
Unix and Windows.
There is this parameter (that a lot of peopled do not like) 'winbind use
default domain =yes', if this is set and nested groups are fixed so that
BUILTIN\users shows users, is there a chance that the group will just
become 'users', which will clash with the Unix group 'users'.
More information about the samba-technical