Alex
2021-Dec-23 11:27 UTC
[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
Rowland, 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
Alex
2021-Dec-29 17:19 UTC
[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
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
Alex
2022-Jan-10 10:21 UTC
[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
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 for83c83 < 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