[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
Alex
samba at abisoft.biz
Mon Jan 10 10:21:43 UTC 2022
Rowland, could you please help me with this? I tried to remove some patches and rebuild but this is very time-consuming and I wasn't able to find the affecting patch yet :(
Also I'm wondering what 2.33.1 and 2.30.2 mean in the patch file, for example:
# diff samba-4.10-redhat.patch.15 samba-4.10-redhat.patch |less
4c4
< Subject: [PATCH 01/48] s3-rpcserver: fix security level check for
---
> Subject: [PATCH 01/88] s3-rpcserver: fix security level check for
83c83
< 2.30.2
---
> 2.33.1
> 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
More information about the samba
mailing list