We had exactly the same issue on RHEL7, updating 4.10.16-15.el7_9 to 4.10.16-17.el7_9.

The more I research it, the more it appears that the newer version of Samba is not playing well with SSSD.  Samba is looking for winbind to do the security, while we have general authentication setup for SSSD.

Samba requires running winbindd process since 2018 or so. This is part of the Samba suite.

https://access.redhat.com/articles/4355391 explains this:

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

A file server capabilities can be enabled on a domain member running under Red Hat Enterprise Linux with the help of Samba suite. Samba suite, when running as a domain member, starts two daemons:

smbd, the main process which handles network connections, file system operations, and remote procedure calls like LSA and NETLOGON. Each connection is handled by a separate smbd child;

winbindd, a process to perform identity resolution for all configured and known domains. Active connection to a domain is handled by a separate winbindd child. winbindd processes connect to domain controllers and perform required LSA and NETLOGON operations against them. Normally, authentication of a user from a trusted domain is delegated to the domain member`s own domain controller which then forwards it further.

Winbind uses a set of identity mapping modules collectively called idmap modules in Samba terminology. Each idmap module represents a strategy to map security identifiers (SIDs) from Active Directory to corresponding POSIX IDs. Since SID namespace in Active Directory is common for all kinds of objects and POSIX ID name space is separate for users and groups, with both POSIX ID name spaces being smaller than a common SID name space, there exist multiple approaches to perform the translation. A choice of a translation method is tightly connected with a specific deployment configuration.

It is possible to configure Red Hat Enterprise Linux system to use winbindd for both system level POSIX IDs retrieval and file server operations in Samba suite. Thanks to winbindd idmap modules support, it is also possible to configure it to look up system identities via SSSD. In the latter case winbindd daemon would still be running but will not provide NSS and PAM services.

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

So if you are not using winbindd but running Samba as a domain member, you should reconsider your configuration. In most cases this simply means to enable winbind systemd service.

Our current configuration does have winbind running, but we're using idmap backend sss:

[global]
    realm = FQDN_DOMAIN
    workgroup = DOMAIN
    security = ads
    kerberos method = system keytab
    template homedir = /home/%U
    idmap config * : backend = tdb
    idmap config * :  range = 10000-199999
    idmap config DOMAIN : backend = sss
    idmap config DOMAIN : range = 200000-2147483647
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    machine password timeout = 0

After the upgrade, winbind enters a failed state and cannot be started again.  Given no other configuration changes, this is suspect.  So far in my testing, the only success I've had is to move away from SSSD as my authentication agent for all realm authentication, and move to winbind.  Am I hearing that SSSD authentication, with Samba winbind is unsupported?

No, that's not correct.

The configuration you have should work with both SSSD and winbindd running. We do test this with IPA and trust to AD, for example.

http://freeipa-org-pr-ci.s3-website.eu-central-1.amazonaws.com/jobs/a7006178-5e00-11ec-a932-fa163e684033/report.html is an example of a successful run of such configuration -- sorry, I don't have RHEL test run public, this is Fedora Rawhide with essentially the same configs.

For IPA case this is automated with 'ipa-client-samba' tool. How it looks internally is described in https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html. For direct AD integration it is basically the same and your configuration should work too.

What exactly does winbindd report on start? Please add 'log level = 10' to see the debug info.

I've done a lot of fiddling with it, and have it in quite the mess presently  I'll revert this to snapshot and grab some clean before and after logs later this afternoon.  Thanks for taking time to look into this with us. :)

Alexander,

Thanks for pointing me to look at my debug logs (I should have done that before I posted the bug report).  Turns out I had a config issue that did not manifest itself as a failure until the upgrade.  Given the change to correct CVE-2020-25717, it's not surprising that the config error broke things.

My logging in winbind indicated the following error:
winbind Could not fetch our SID - did we join?

Turns out winbind was NOT running, nor do I think it ever was.  I reverted to snapshot, and ultimately a few different versions of smb.conf, sssd.conf, realmd.conf from backup.  I found that in my only working config for 4.14.5-2, I had this commented out in smb.conf:

"# security = ads"

If I uncommented that and attempted to start winbind, it would fall down.  If I commented it, winbind would start, but it had lots of errors, including "did we join?"  None-the-less, the Samba shares would work without winbind on the older version, but not with the newer.

Ultimately what I did to fix the issue:

I backed up my smb.conf, sssd.conf, realmd.conf files, then removed the system from the domain, then re-added it:

# realm leave
# net ads join -U domain_admin_user
# adcli join domain.fqdn -U domain_admin_user

I did both net ads join and adcli join to get both the winbind and sssd components registered.  I then copied my backed up sssd.conf to /etc/sssd.

# cp sssd.conf /etc/sssd/sssd.conf
# systemctl restart winbind sssd smb

After verifying that all services would start clean, and stay up, combined with the ability to access my shares, I then took the plunge and upgraded again:

Packages Altered:
    Upgrade  samba-common-tools-4.14.5-7.el8_5.x86_64    @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-common-tools-4.14.5-2.el8.x86_64      @@System
    Upgrade  libwbclient-4.14.5-7.el8_5.x86_64           @rhel-8-for-x86_64-baseos-rpms
    Upgraded libwbclient-4.14.5-2.el8.x86_64             @@System
    Upgrade  samba-client-4.14.5-7.el8_5.x86_64          @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-client-4.14.5-2.el8.x86_64            @@System
    Upgrade  samba-client-libs-4.14.5-7.el8_5.x86_64     @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-client-libs-4.14.5-2.el8.x86_64       @@System
    Upgrade  libsmbclient-4.14.5-7.el8_5.x86_64          @rhel-8-for-x86_64-baseos-rpms
    Upgraded libsmbclient-4.14.5-2.el8.x86_64            @@System
    Upgrade  samba-winbind-4.14.5-7.el8_5.x86_64         @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-winbind-4.14.5-2.el8.x86_64           @@System
    Upgrade  samba-common-libs-4.14.5-7.el8_5.x86_64     @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-common-libs-4.14.5-2.el8.x86_64       @@System
    Upgrade  samba-winbind-modules-4.14.5-7.el8_5.x86_64 @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-winbind-modules-4.14.5-2.el8.x86_64   @@System
    Upgrade  samba-libs-4.14.5-7.el8_5.x86_64            @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-libs-4.14.5-2.el8.x86_64              @@System
    Upgrade  samba-common-4.14.5-7.el8_5.noarch          @rhel-8-for-x86_64-baseos-rpms
    Upgraded samba-common-4.14.5-2.el8.noarch            @@System

After the upgrade I restarted all three services I tested again, and everything worked.  After, I did a reboot... but then I could no longer log in with a domain account OR access the shares???!!

Logged in as a non-domain account and checked, and both the sssd and winbind services were disabled for some reason.  I enabled them, did another reboot, and now we're cooking with fire!

Below are my sssd, samba.conf (global) and realmd.conf files, sanitized of course.  Hopefully this will help someone else out if they are having an issue.  From my perspective, this was and is a non-bug and can be closed. :)

Thanks,
Jeff

======================================================

# cat /etc/sssd/sssd.conf

[sssd]
domains = domain.fqdn
config_file_version = 2
services = nss, pam
default_domain_suffix = domain.fqdn

[nss]
homedir_substring = /home

[pam]

[domain/domain.fqdn]
ad_domain = domain.fqdn
krb5_realm = DOMAIN.FQDN
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = True
fallback_homedir = /home/%u
access_provider = simple
full_name_format = %1$s
simple_allow_groups = admin_group_here

======================================================

# ​cat /etc/realmd.conf
[providers]
   ​samba = no

[active-directory]
   ​default-client = sssd
   ​# default-client = winbind

======================================================

[global]
   ​realm = DOMAIN.FQDN
   ​workgroup = domain
   ​security = ads
   ​kerberos method = system keytab
   ​template homedir = /home/%U
   ​idmap config * : backend = tbd
   ​idmap config * :  range = 10000-199999
   ​idmap config domain : backend = sss
   ​idmap config domain : range = 200000-2147483647
   ​load printers = no
   ​printing = bsd
   ​printcap name = /dev/null
   ​disable spoolss = yes
   ​machine password timeout = 0
#   log level = 10

As per comment #7 closing as NOTABUG