[Pkg-samba-maint] Bug#972223: Bug#972223: Acknowledgement (samba: NT4-style domain member doesn't work without winbind, but even with it, doesn't work)

[Josip Rodin]

On Sun, Oct 18, 2020 at 11:12:15AM +0200, Josip Rodin wrote:
> On Sat, Oct 17, 2020 at 01:09:08PM +0200, Josip Rodin wrote:
> > [2020/10/17 10:26:37.521971,  3, pid=16890, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:151(token_contains_name)
> >   token_contains_name: returning false for users
> > [2020/10/17 10:26:37.522069, 10, pid=16890, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:222(user_ok_token)
> >   User joy not in 'valid users'
> > 
> > I'm afraid I haven't had the time yet to figure out why the netgroup code
> > can't resolve the users group (I'll keep at it).
> 
> I added a bit more debugging and found the following pattern:
> 
> [2020/10/18 09:04:55.557863,  3, pid=20645, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:432(lookup_name)
>   lookup_name: lookup for Unix Group\users succeeded: name (null), domain (null), sid ^A^B, type ^B
> [2020/10/18 09:04:55.557938,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-21-145766654-2861277506-3272706772-1001000 and S-1-22-2-100
> [2020/10/18 09:04:55.558008,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-21-145766654-2861277506-3272706772-513 and S-1-22-2-100
> [2020/10/18 09:04:55.558052,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-1-0 and S-1-22-2-100
> [2020/10/18 09:04:55.558094,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-2 and S-1-22-2-100
> [2020/10/18 09:04:55.558134,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-5-11 and S-1-22-2-100
> [2020/10/18 09:04:55.558173,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-22-1-1000 and S-1-22-2-100
> [2020/10/18 09:04:55.558213,  3, pid=20645, effective(0, 0), real(0, 0)] ../libcli/security/dom_sid.c:85(dom_sid_equal)
>   dom_sid_equal: Comparing SID S-1-22-2-1000 and S-1-22-2-100
> [2020/10/18 09:04:55.558253,  3, pid=20645, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:139(token_contains_name)
>   token_contains_name: nt_token_check_sid failed for users, (null)
> [2020/10/18 09:04:55.558321,  3, pid=20645, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:155(token_contains_name)
>   token_contains_name: returning false for users
> [2020/10/18 09:04:55.558364, 10, pid=20645, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:226(user_ok_token)
>   User joy not in 'valid users'
> 
> This S-1-22-2- base SID seemed indicative, so I googled that, but the best
> explanation I could find was in a question at
> https://stackoverflow.com/questions/31109871/mapping-sambas-s-1-22-12-sid-into-names
> where it says this is something that "Samba uses" for groups.
> 
> Is this the idmap setup that I don't seem to have in my old config?

OK so after some more discussion with the folks in #samba on IRC, I decided
to try the method of not having a domain member server on the file server,
but a classic (NT4-style) backup domain controller instead, with the ldapsam
setup directly on it.

This generally works much better, but I observed users having their SID
lists expanded partially, i.e. the LDAP clearly had them in e.g. 5 groups,
but Samba only saw 3 groups - based on the output of security_token_debug().

This was even after I destroyed all obvious traces of winbind and whatever.

Then I completely uninstalled Samba from the machine, which eliminated the
entire /var/lib/samba directory, and reinstalled the software and re-did the
net(8) and smbpasswd(8) commands needed, and now it miraculously all works
just fine.

So it looks like something is definitely wrong with how Winbind/idmap
stuff functions with this particular LDAP directory, yet it's completely
obfuscated why.

This also makes me even more afraid to move from NT4-style to AD-style,
because who know what else might fail there, too...

-- 
Josip Rodin