View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015525||CentOS-7||samba||public||2018-12-04 15:30||2019-01-14 11:36|
|Platform||x86_64||OS||CentOS||OS Version||7.6.1810 (Core)|
|Target Version||Fixed in Version|
|Summary||0015525: Samba on CentOS 7.x suddenly ceases to authenticate|
As of December 4th, 2018, Samba shares on (official) CentOS 7.x
*suddenly* become inaccessible from Windows 10 workstations, reporting
Authentication failure is reported, but the same shares *are*
accessible from GNU/Linux workstations, using the known credentials
Samba server: samba-4.8.3-4.el7.x86_64
(official package from CentOS 7.x repo)
Samba clients: Windows 10 + all updates, as of December 4th, 2018
No errors or rejects are reported in logs, log level 4 ("Allowing
Thanks a lot for your kind help!
|Steps To Reproduce||I suddenly happened on December 4th, 2018 on many CentOS 7.x systems.|
|Additional Information||I cannot verify if this is a Samba or a Windows issue (occuring after automatic updates).|
|Tags||No tags attached.|
I can confirm similar behavior in our environment. Servers are SSSD + AD configured. Mac and WIndows clients fail with either username/pass or Kerberos auth. Samba claims that cifs/ SPN is missing for kerberos auth, and simply bad password for user/pass clients.
Server on Centos 7.5 is still authenticating clients no issue
|Update: Removing SSSD and Samba from Centos 7.6 server and manually installing SSSD and Samba RPMs from Centos 7.5 base/updates restored service.|
Confirming in our environment also. Several file servers (10+) patched overnight from Samba 4.7.1-9.el7_5 to 4.8.3-4.el7 on x86_64 cause the behaviour documented above. Also using SSSD+AD server side, with Windows and Mac clients. Seems to occur on client machines that aren't bound to AD, and connecting with a password challenge. AD bound machines (machines with a kerberos object in AD) don't appear to have the problem.
Will attempt the Samba+SSSD rollback shortly.
|Downgrading samba packages to 4.7* solved our issue for now.|
|Confirming problem after update. Updated Samba (4.8.3-4) works from linux (cifs) and mac (10.12.6 (16G1710)) for both guest (public share) and real user (identified by password), but not from windows (Win7 x64). Simple setup, no LDAP.|
I have the same problem. on Windows 10 and with smbclient if I do not give the -W <WORKGROUP> option.
Got Error NT_STATUS_LOGON_FAILURE
Will try to install the rpm from CentOS 7.5 to fix it
After installing samba-winbind
systemctl start winbind
all works - now it looks good
When upgrading to samba >= 4.8.x you are required to run Winbind. Look at the release notes:
Domain member setups require winbindd
Setups with "security = domain" or "security = ads" require a
running 'winbindd' now. The fallback that smbd directly contacts
domain controllers is gone.
Please note the following entry in the upstream RHEL 7.6 Release Notes: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.6_release_notes/new_features_authentication_and_interoperability
To quote: The smbd service no longer queries user and group information from Active Directory domain controllers and NT4 primary domain controllers directly. Installations with the security parameter set to ads or domain now require that the winbindd service is running.
Also do note that when you update to samba 4.8.x and enable winbind, if you were restricting your shares with
write list = @group_name1 @group_name2
Now it may be necessary to adjust those groups using your Domain name, ie. if your domain is called AD, then
write list =@AD\group_name1 @AD\group_name2
Failure to do that will result in permission denied errors.
We have the same problem here and running winbind solved too. Thanks to rsy.
But an interesting fact, we have 2 servers running samba, both were updated to version 4.8.3-4 and both use security = user.
I had problems with the one that uses LDAP to authenticate users, but the other one that I use local accounts was working OK.
So, It has some effect in LDAP auth too, not just samba with "security = domain" or "security = ads".
sorry for that but installing winbind will fix some issues but not the following:
machine joined to active directory with realmd and working with sssd and kerberos for ssh is still broken even if you change from sssd to winbind, when using guest sharing with security=user. users from windows cannot connect anymore to this shares when connecting to hostname. it works to connect to ip or an cname of the machine.
error when connecting to hostname NT_STATUS_INVALID_PARAMETER
switching back to samba and sssd to the versions before centos 7.6 are fixing the issue. samba fixes the NT_STATUS_INVALID_PARAMETER sssd is necessary to get sshd login working for ad accounts. sssd version from centos 7.6 with samba from centos 7.5 results in errors when trying kerberos.
we have an issue even with winbind started. With random clients (Win, Linux, ...) NT_STATUS_LOGON_FAILURE
And the issue appears only with new samba 4.8.
Configuration: samba, winbind with ssd as backend
I have attached logs as well as config files...
logs.zip (1,830,823 bytes)
smb.conf (2,395 bytes)
sssd.conf (1,246 bytes)
There's a bit more to this, I'm not sure if this was always the case in the RHEL 7 System Administrator's Guide but it now contains this comment:
"Red Hat only supports running Samba as a server with the winbindd service to provide domain users and groups to the local system. Due to certain limitations, such as missing Windows access control list (ACL) support and NT LAN Manager (NTLM) fallback, the System Security Services Daemon (SSSD) is not supported."
We were previously using Samba with the system bound the AD with SSSD that in turn was making use of sssd-libwbclient for mapping.
I also notice that RHEL/CentOS 7.6 ships with a package called sssd-winbind-idmap which contains /usr/lib64/samba/idmap/sss.so the man page for which says:
"The idmap_sss module provides a way to call SSSD to map UIDs/GIDs and SIDs."
With a config example:
idmap config * : backend = sss
So if simply starting winbind hasn't worked for you, are you using SSSD?
I would say the guide was updated recnetly: https://bugzilla.redhat.com/show_bug.cgi?id=1663323
Otherwise sssd is exactly what we have in place...
The official line from Red Hat as of 7.6 is that since Samba 4.8 using SSSD as part of the directory integration with AD is not supported. If you've been using directory hosted uid/gid numbers then switching from sssd to winbind may be straight forward. If you've been using rid generated uid/gid numbers then these are likely to be different using winbind meaning that all the identifiers on effected filesystems will need to be adjusted.
I'm still looking as to whether idmap_sss might be a way out here, otherwise we're looking at moving back to AD hosts uid/gids and resetting uid/gids on many many millions of files across many servers.
Not impressed that they did this Samba re-base mid 7.* stream when so much of the documentation was pushing SSSD.
These two sssd-users threads have more information on possible ways to get SSSD and Samba to co-exist:
|2018-12-04 15:30||rsandu||New Issue|
|2018-12-05 21:12||ghuntress||Note Added: 0033229|
|2018-12-05 22:02||ghuntress||Note Added: 0033230|
|2018-12-06 00:38||cecentos||Note Added: 0033234|
|2018-12-06 09:34||oernii||Note Added: 0033241|
|2018-12-11 20:02||Cyril F.||Note Added: 0033313|
|2018-12-14 09:33||rsy||Note Added: 0033335|
|2018-12-14 11:15||rsy||Note Added: 0033337|
|2018-12-14 16:email@example.com||Note Added: 0033338|
|2018-12-14 16:22||TrevorH||Note Added: 0033339|
|2018-12-14 16:firstname.lastname@example.org||Note Added: 0033340|
|2018-12-14 16:41||vgeraseev||Note Added: 0033341|
|2018-12-15 16:24||mom20xx||Note Added: 0033356|
|2019-01-08 12:31||janzhanal||File Added: logs.zip|
|2019-01-08 12:31||janzhanal||File Added: smb.conf|
|2019-01-08 12:31||janzhanal||File Added: sssd.conf|
|2019-01-08 12:31||janzhanal||Note Added: 0033536|
|2019-01-09 17:40||carwyn||Note Added: 0033548|
|2019-01-10 09:38||janzhanal||Note Added: 0033553|
|2019-01-10 18:21||carwyn||Note Added: 0033560|
|2019-01-14 11:36||carwyn||Note Added: 0033578|