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
