Rowland Penny
2022-Jan-10 10:55 UTC
[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
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
Alex
2022-Jan-10 12:20 UTC
[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
Rowland,> 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![skip]> Have you considered using Debian 11 with the Samba packages from > Louis's repo: > https://apt.van-belle.nl/simple-repo-setup.txtI'd love to switch to Louis's repo, but this server is CentOS 7. -- Best regards, Alex