This looks similar to other bugs where winbindd is not running. Using Samba in AD environment without winbindd is not supported since 2018.

Please see https://bugzilla.redhat.com/show_bug.cgi?id=2033405 for details and advises how to correct your setup.

Thanks for your quick answer.
I'm not familiar with samba stuff, so a question:
you refer to a configuration which seems to use an AD, and i use only ldap + mit kerberos. This works perfectly until now with a simple configuration:

[global]
   kerberos method = system keytab
   realm = MYREALM   
   guest account = nobody
   map to guest = bad user


I installed windbind + sssd, and i got the  same error

Does this means what I'm doing  is not possible anymore?

Correct. With the fixes for CVE-2020-25717 Samba consolidated all configurations requiring Kerberos to be:

- domain member of Active Directory or IPA
- domain controller AD
- trust controller IPA

All these configurations have particular setup steps. Anything outside those are not supported and with CVE-2020-25717 protection are rejected by Samba.

In particular, your configuration is not valid and you need to correctly join your system to continue using Kerberos setup.

There is a number of fixes that restore some of the related functionality, as mentioned in https://www.samba.org/samba/security/CVE-2020-25717.html

We haven't yet checked them for backports but these fixes are part of the rebase in CentOS 8 Stream and CentOS 9 stream already. If that helps to validate they fix your scenario, please try and report back here.

Hi Alexander, good afternoon!

I am also seeing the same issue as Francois, and I expect that I am using a very similar configuration.  But I have done some test patching, and I think I am able to give you the confirmation that you are looking for.  I believe that the patch in [Samba bug 14922](https://bugzilla.samba.org/show_bug.cgi?id=14922) fixes the problem.  I am right now running a Samba server in production that includes the fix ("Patches for v4-13-test", patched on top of samba 4.10.16-17).  The patched Samba server has been running since last night, and users are connected.

The rest of this post is just detail.  First, I wanted to give our current Samba configuration, and the reason why we have it set up the way we do.  Then I'll explain more how I found the fix myself, added the patch to the samba package, and deployed it to production (last night).

The global part of our smb.conf looks like this (with some things, like interface configuration, removed to save space):

[global]
    workgroup = STANFORD
    realm = stanford.edu
    security = user
    encrypt passwords = yes
    server string = SCG SMB Gateway
    password server = krb5auth1.stanford.edu, krb5auth2.stanford.edu, krb5auth3.stanford.edu
    kerberos method = dedicated keytab
    dedicated keytab file = /etc/krb5.keytab
    passdb backend = tdbsam

(Let me know if you need our full smb.conf!)

We are using our institutional Kerberos to handle user authentication, but then we are using 'local' users and groups.  I put "local" in quotes because our systems are actually pulling user information from LDAP (via SSSD).

This kind of setup is not that unusual in academic and research institutions.  Francois, for example, is from the French Laboratoire des Sciences du Climat et de l'Environnement, which studies climate and climate change.  I'm from the Stanford Research Computing Center, where we use Samba gateways to provide convenient access to some storage.  The person who originally reported this regression to the Samba team is Sebastien Chapiron, from the French Agence nationale de la sécurité des systèmes d'information, France's national cybersecurity agency.

These are likely environments that don't use Active Directory, and cater to users of systems that are probably not even joined to an AD domain.  I know that is true for Stanford; we do have an Active Directory domain, but not many systems (especially non-Windows systems) use it.  (By the way, our Kerberos realm name is actually `stanford.edu`, not `STANFORD.EDU`; Stanford started using Kerberos before the convention to uppercase realm names.).

Once we got reports of people being unable to authenticate to Samba, one of my coworkers (Taymoor Arif) was able to confirm that the issue was introduced by samba-4.10.16-17 (we were on samba-4.10.16-15).  My coworker Kilian Cavalotti theorized that it was due to CVE-2020-25717.  I found the same [security announcement](https://www.samba.org/samba/security/CVE-2020-25717.html) that you mentioned, and I noted the last addition—the one at the end of the announcement—which referred to standalone setups with MIT Kerberos and [Samba bug](https://bugzilla.samba.org/show_bug.cgi?id=14922).

Yesterday evening, I rolled out a patched samba package to one of our SCG Samba servers.  Here are the basic steps I used to build the packages:

1. I grabbed the source package for samba-4.10.16-17.el7.x86_64, and unpacked it to `~/rpmbuild`.
2. I added the patch from [Patches for v4-13-test](https://bugzilla.samba.org/attachment.cgi?id=17047) to the `~/rpmbuild/SOURCES` directory, then updated `~/rpmbuild/SPECS/samba.spec` to include that patch (after "samba-4.10-redhat.patch", but before "libldb-require-version-1.5.4.patch").  I also changed the spec file to set "main_release" to "17.1".
3. I built the packages using `rpmbuild -ba ~/rpmbuild/SOURCES/samba.spec`.
4. I installed the newly-built packages onto one of our Samba servers, using yum.

I hope all of this information explains why we have Samba configured the way that we do, and gives you the confirmation needed to backport the MIT Kerberos fix into 7.  If you need any more information from me, please let me know!

Hello everybody

Thanks for your help and support. 
At the moment, following the link provided by Alexander, I just use the workaround given using "username map script". It works fine for me.
This help to wait for a backport.
I confirm that the way we use samba is certainly basic, but we escape from the AD suff, and it's very useful.

Francois, Karl,

thank you for all the feedback. I am still on vacation (back on Monday) as well as Andreas and few other our colleagues who maintain Samba packages in RHEL.

Next week we'll look into backports but it will sure take some time to get through normal RHEL processes for updates.

I want to note, though, that there is ongoing work upstream to make sure use of Kerberos is tightened when Active Directory-like environments are in use. This might affect a plain Kerberos environment as well and there is also an effort in MIT Kerberos upstream to make corresponding changes for plain KDC environments as well. It may or may not affect your uses but it will certainly continue tightening name-based authorization to avoid issues similar to the CVEs in Active Directory implementations we reported in several last years and which were fixed in Microsoft's Active Directory implementation and in Samba in a coordinated November 2021 update. The work on improving in this area is ongoing.

To recap, below references from my upcoming blog about it:

---------------------------------------------------------
On November 9th 2021 Microsoft did their traditional monthly security
update. Four issues among the published security fixes were in the area
of Active Directory and were attributed to Samba Team and its members:

  - CVE-2021-42291: Active Directory Domain Services Elevation of
    Privilege Vulnerability, Active Directory permissions updates,
    https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42291

  - CVE-2021-42287: Active Directory Domain Services Elevation of
    Privilege Vulnerability, Authentication updates,
    https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42287

  - CVE-2021-42282: Active Directory Domain Services Elevation of
    Privilege Vulnerability, Verification of uniqueness for user
    principal name, service principal name, and the service principal
    name alias,
    https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42282

  - CVE-2021-42278: Active Directory Domain Services Elevation of
    Privilege Vulnerability, Active Directory Security Accounts Manager
    hardening changes,
    https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42278

A coordinated security release of Samba 4.15.2 by the Samba Team fixes
eight security issues, some of them around the same theme as Microsoft's
ones:

  - CVE-2016-2124:  SMB1 client connections can be downgraded to
    plaintext authentication,
    https://www.samba.org/samba/security/CVE-2016-2124.html (Something
    left from the Badlock bugs)

  - CVE-2020-25717: A user on the domain can become root on domain
    members, https://www.samba.org/samba/security/CVE-2020-25717.html,
    (PLEASE READ! There are important behaviour changes described)

  - CVE-2020-25718: Samba AD DC did not correctly sandbox Kerberos
    tickets issued by an RODC,
    https://www.samba.org/samba/security/CVE-2020-25718.html

  - CVE-2020-25719: Samba AD DC did not always rely on the SID and PAC in
    Kerberos
    tickets,https://www.samba.org/samba/security/CVE-2020-25719.html

  - CVE-2020-25721: Kerberos acceptors need easy access to stable AD
    identifiers (eg objectSid),
    https://www.samba.org/samba/security/CVE-2020-25721.html

  - CVE-2020-25722: Samba AD DC did not do sufficient access and
    conformance checking of data stored,
    https://www.samba.org/samba/security/CVE-2020-25722.html

  - CVE-2021-3738:  Use after free in Samba AD DC RPC server,
    https://www.samba.org/samba/security/CVE-2021-3738.html

  - CVE-2021-23192: Subsequent DCE/RPC fragment injection vulnerability,
    https://www.samba.org/samba/security/CVE-2021-23192.html

The scope of changes is enormous. Just on the Samba side there are 220
patches between 4.15.2 and the previous minor release, 4.15.1. However,
Samba 4.15.1 release was a preparation -- it also merged some 3000
patches, establishing a ground for testing Kerberos protocol behavior.
These tests helped to reduce behavior differences between Samba AD and
Windows-based Active Directory deployments and made the security release
possible at all.

---------------------------------------------------------

I'm also see the same issue and have a support ticket in.
RHEL 7.9 with basically the same setup as Stanford.  I resolved it temporarily by rolling back to the previous minor version.  All ready use a user mapping script to map principals to uids.

Public update: 

we are working on RHEL 7.9.z update that will incorporate the fixes to regressions as outlined in the CVE-2020-25717 document on Samba website (links are in comment #9).

As with any updates to RHEL, no exact dates can be communicated.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Critical: samba security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:0328