[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
Rowland Penny
rpenny at samba.org
Mon Jan 10 10:55:28 UTC 2022
On Mon, 2022-01-10 at 13:21 +0300, Alex via samba wrote:
> 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
>
Have you considered using Debian 11 with the Samba packages from
Louis's repo:
https://apt.van-belle.nl/simple-repo-setup.txt
Rowland
More information about the samba
mailing list