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
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
Robert Marcano
2022-Jan-10 14:06 UTC
[Samba] Authentication issue after updating samba on CentOS 7 (from yum)
On 1/10/22 6:21 AM, 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.1I was hit by this problem, apparently is a missing backported patch [1]. The workaround at [2] is working for me. Just updated the domain name on the script and placed it instead on /var/lib/samba/scripts to make SELinux happy. Will wait for an updated RPM and remove the workaround for testing at that time. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2036595 [2] https://bugzilla.samba.org/show_bug.cgi?id=14901#c0> > >> 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? >