Bug 2033405
Summary: | Samba Upgrade Breaks Shares | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Jeff Scrivener <fregiventum> |
Component: | samba | Assignee: | Andreas Schneider <asn> |
Status: | CLOSED NOTABUG | QA Contact: | sssd-qe <sssd-qe> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.4 | CC: | abokovoy, dkarpele, gdeschner, jarrpa, jeff.scrivener, voetelink |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-12-18 10:30:07 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jeff Scrivener
2021-12-16 18:00:00 UTC
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 |