[Samba] Authentication issue after updating samba on CentOS 7 (from yum)

Wed Dec 29 17:19:31 UTC 2021

It appears this issue is not connected with the bug 14901: I extracted and applied the patch to idmap_nss.c from the mentioned comment (and the re-built the rpms) and that didn't fix the issue.
Analyzing patch file from the package - samba-4.10-redhat.patch - I see 40 patches have been added since 4.10.16-15. If you guys have any ideas how to find which patch might have broken things besides extracting and applying the patches one by one, that would be greatly appreciated!

This is the list of patches applied since 4.10.16-15:
Subject: [PATCH 49/88] CVE-2016-2124: s4:libcli/sesssetup: don't fallback to
Subject: [PATCH 50/88] CVE-2016-2124: s3:libsmb: don't fallback to non spnego
Subject: [PATCH 51/88] s3/auth: use set_current_user_info() in
Subject: [PATCH 52/88] selftest: Fix ktest usermap file
Subject: [PATCH 53/88] selftest/Samba3: replace (winbindd => "yes", skip_wait
Subject: [PATCH 54/88] CVE-2020-25719 CVE-2020-25717: selftest: remove
Subject: [PATCH 55/88] CVE-2020-25717: s3:winbindd: make sure we default to
Subject: [PATCH 56/88] CVE-2020-25717: s4:auth/ntlm: make sure
Subject: [PATCH 57/88] CVE-2020-25717: s4:torture: start with authoritative =
Subject: [PATCH 58/88] CVE-2020-25717: s4:smb_server: start with authoritative
Subject: [PATCH 59/88] CVE-2020-25717: s4:auth_simple: start with
Subject: [PATCH 60/88] CVE-2020-25717: s3:ntlm_auth: start with authoritative
Subject: [PATCH 61/88] CVE-2020-25717: s3:torture: start with authoritative =
Subject: [PATCH 62/88] CVE-2020-25717: s3:rpcclient: start with authoritative
Subject: [PATCH 63/88] CVE-2020-25717: s3:auth: start with authoritative = 1
Subject: [PATCH 64/88] CVE-2020-25717: auth/ntlmssp: start with authoritative
Subject: [PATCH 65/88] CVE-2020-25717: loadparm: Add new parameter "min domain
Subject: [PATCH 66/88] CVE-2020-25717: s3:auth: let
Subject: [PATCH 67/88] CVE-2020-25717: s3:auth: Check minimum domain uid
Subject: [PATCH 68/88] CVE-2020-25717: s3:auth: we should not try to
Subject: [PATCH 69/88] CVE-2020-25717: s3:auth: no longer let check_account()
Subject: [PATCH 70/88] CVE-2020-25717: s3:auth: remove fallbacks in
Subject: [PATCH 71/88] CVE-2020-25717: s3:auth: don't let create_local_token
Subject: [PATCH 72/88] CVE-2020-25717: Add FreeIPA domain controller role
Subject: [PATCH 73/88] CVE-2020-25717: auth/gensec: always require a PAC in
Subject: [PATCH 74/88] CVE-2020-25717: s4:auth: remove unused
Subject: [PATCH 75/88] CVE-2020-25717: s3:ntlm_auth: fix memory leaks in
Subject: [PATCH 76/88] CVE-2020-25717: s3:ntlm_auth: let
Subject: [PATCH 77/88] CVE-2020-25717: s3:auth: let
Subject: [PATCH 78/88] CVE-2020-25717: selftest: configure 'ktest' env with
Subject: [PATCH 79/88] CVE-2020-25717: s3:auth: let
Subject: [PATCH 80/88] CVE-2020-25717: s3:auth: simplify
Subject: [PATCH 81/88] CVE-2020-25717: s3:auth: simplify
Subject: [PATCH 82/88] krb5pac.idl: Add ticket checksum PAC buffer type
Subject: [PATCH 83/88] security.idl: Add well-known SIDs for FAST
Subject: [PATCH 84/88] krb5pac.idl: Add missing buffer type values
Subject: [PATCH 85/88] CVE-2020-25719 krb5pac.idl: Add PAC_ATTRIBUTES_INFO PAC
Subject: [PATCH 86/88] CVE-2020-25719 krb5pac.idl: Add PAC_REQUESTER_SID PAC
Subject: [PATCH 87/88] CVE-2020-25721 krb5pac: Add new buffers for
Subject: [PATCH 88/88] IPA DC: add missing checks

> I think I found what's going on. It appears the recent patch (https://bugzilla.samba.org/show_bug.cgi?id=14901#c14) hasn't been applied to CentOS 7 4.10.16-17 package:
> # yumdownloader --source samba-4.10.16-17\*
> ...
> samba-4.10.16-17.el7_9.src.rpm                                                                                                         |  12 MB  00:00:09
> # rpm -ihv samba-4.10.16-17.el7_9.src.rpm
> Updating / installing...
>    1:samba-0:4.10.16-17.el7_9         ################################# [100%]
> ...
> # rpmbuild -bp samba.spec
> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.ygAPHU
> + umask 022
> + cd /root/rpmbuild/BUILD
> + xzcat /root/rpmbuild/SOURCES/samba-4.10.16.tar.xz
> + gpgv2 --quiet --keyring /root/rpmbuild/SOURCES/gpgkey-52FBC0B86D954B0843324CDC6F33915B6568B7EA.gpg /root/rpmbuild/SOURCES/samba-4.10.16.tar.asc -
> gpgv: Signature made Mon May 25 11:32:59 2020 MSK using DSA key ID 6568B7EA
> gpgv: Good signature from "Samba Distribution Verification Key <samba-bugs at samba.org>"
> + cd /root/rpmbuild/BUILD
> + rm -rf samba-4.10.16
> + /usr/bin/xz -dc /root/rpmbuild/SOURCES/samba-4.10.16.tar.xz
> + /usr/bin/tar -xf -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd samba-4.10.16
> + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
> + /usr/bin/cat /root/rpmbuild/SOURCES/samba-4.10-redhat.patch
> + /usr/bin/patch -p1 -s
> + /usr/bin/cat /root/rpmbuild/SOURCES/libldb-require-version-1.5.4.patch
> + /usr/bin/patch -p1 -s
> + exit 0

> # grep libcli/security/dom_sid.h /root/rpmbuild/BUILD/samba-4.10.16/source3/winbindd/idmap_nss.c
> #

> I'm going to email Andreas Schneider (he seems to be a packager of Samba in RH) to apply the recent patch and release the new package. Please, let me know if there's something else I can do to speed up the fix.

>>>> > >     idmap config * : backend = tdb
>>>> > >     idmap config * : range = 16777216-33554431
>>>> > Is there some reason for that range ? It will allow you 16777215
>>>> > users
>>>> > & groups for something that requires only about 200.
>>>> 
>>>> I think it's a legacy. Don't remember why it's here. I'll try to
>>>> remove it.

>>> You are probably stuck with it.

>> Anyway, they don't seem to correlate with the current issue, right?

>>>> 
>>>> > >     idmap config DOMAIN:unix_primary_group = yes
>>>> > Do your users have gidNumber attributes.
>>>> 
>>>> Yes, they do. This came from MS Services for Unix.

>>> Have you actually checked, MS-SFU didn't add a gidNumber attribute to
>>> users, unless you told it to.

>> Yes, of course. Here is a sample of AD user entry: https://paste.ee/p/7X6N0

>>>> > >    winbind use default domain = true
>>>> > >    winbind offline logon = false
>>>> > >    winbind enum users = Yes
>>>> > >    winbind enum groups = Yes
>>>> > You do not need the 'enum' lines, it works without them.
>>>> 
>>>> There was an issue w/o the enum lines. Unfortunately, I don't
>>>> remember exactly what it was, probably couldn't retrieve groups from
>>>> the AD with "getent group" command.

>>> Adding those lines would not fix such a problem, either it would work
>>> or it wouldn't. All those lines do is to get 'getent user' to display
>>> all users and 'getent group' to display all groups, along with slowing
>>> everything down.

>> So, I was right :) I don't see any slowness, actually. Everything worked pretty good before this update has come.

>>>> 
>>>> > > [username]
>>>> > >         comment = username's home
>>>> > >         path = /home/username
>>>> > >         read only = No
>>>> > >         create mode = 0660
>>>> > >         valid users = username
>>>> > As noted above, why are you not using '[homes]' ?
>>>> 
>>>> It's b/c most users are prohibited from using this server. So, I
>>>> allowed homes on this server for just a few of them directly.

>>> So does that mean you have multiple '[username]' shares in smb.conf ?

>> Yeah, just like this one. I skipped them for the letter's size sake.

>>>>  I did that both (changed min uid to 0 and set a user.map file) -
>>>> still can't log in :(

>>> This is very strange, I am using Samba 4.15.3 with this smb.conf and I
>>> can log in:

>> [skip]

>> Any ideas what to do?

>> -- 
>> Best regards,
>> Alex

> -- 
> Best regards,
> Alex

-- 
Best regards,
Alex