Nesting of local groups (SID_NAME_ALIAS)

[Rowland Penny]

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:
>>> Hi,
>>>
>>> windbind does not correctly display members for e.g. BUILTIN/users. 
>>> It shows nothing:
>>>
>>> ./bin/wbinfo --group-info BUILTIN/users
>>> BUILTIN/users:x:100001:
>>>
>>>
>>> Given that "BUILTIN\Users" has 1 member "ADDOMAIN\Domain Users", it 
>>> should instead show:
>>>
>>> ./bin/wbinfo --group-info "ADDOMAIN/domain users"
>>> ADDOMAIN/domain 
>>> 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 
>>> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/597504d8-5408-4629-9d81-aab661e6c953:
>>>
>>> /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,
>>> Pavel
>>
>> 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:
> 
> https://gitlab.com/samba-team/devel/samba/-/blob/master/source3/winbindd/winbindd_rpc.c#L509
> 
> dcerpc_samr_GetAliasMembership() is wrong, should be 
> dcerpc_samr_GetMembersInAlias()
> 
> 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'.

Rowland