View Issue Details

IDProjectCategoryView StatusLast Update
0015525CentOS-7sambapublic2019-07-23 11:44
Reporterrsandu 
PriorityhighSeverityminorReproducibilityalways
Status closedResolutionnot fixable 
Platformx86_64OSCentOSOS Version7.6.1810 (Core)
Product Version 
Target VersionFixed in Version 
Summary0015525: Samba on CentOS 7.x suddenly ceases to authenticate
DescriptionHello,

As of December 4th, 2018, Samba shares on (official) CentOS 7.x
*suddenly* become inaccessible from Windows 10 workstations, reporting
"bad password".

Authentication failure is reported, but the same shares *are*
accessible from GNU/Linux workstations, using the known credentials
(user, password).


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
Access", etc.).


Thanks a lot for your kind help!

Best regards,
Răzvan
Steps To ReproduceI suddenly happened on December 4th, 2018 on many CentOS 7.x systems.

Additional InformationI cannot verify if this is a Samba or a Windows issue (occuring after automatic updates).
TagsNo tags attached.
abrt_hash
URL

Activities

ghuntress

ghuntress

2018-12-05 21:12

reporter   ~0033229

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
ghuntress

ghuntress

2018-12-05 22:02

reporter   ~0033230

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.
cecentos

cecentos

2018-12-06 00:38

reporter   ~0033234

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.
oernii

oernii

2018-12-06 09:34

reporter   ~0033241

Downgrading samba packages to 4.7* solved our issue for now.
Cyril F.

Cyril F.

2018-12-11 20:02

reporter   ~0033313

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.
rsy

rsy

2018-12-14 09:33

reporter   ~0033335

Hello,
 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
rsy

rsy

2018-12-14 11:15

reporter   ~0033337

Update:
After installing samba-winbind
and
systemctl start winbind

all works - now it looks good
dijuremo@gmail.com

dijuremo@gmail.com

2018-12-14 16:18

reporter   ~0033338

When upgrading to samba >= 4.8.x you are required to run Winbind. Look at the release notes:

https://www.samba.org/samba/history/samba-4.8.0.html

Excerpt below....

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.
TrevorH

TrevorH

2018-12-14 16:22

manager   ~0033339

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.
dijuremo@gmail.com

dijuremo@gmail.com

2018-12-14 16:30

reporter   ~0033340

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.
vgeraseev

vgeraseev

2018-12-14 16:41

reporter   ~0033341

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".
mom20xx

mom20xx

2018-12-15 16:24

reporter   ~0033356

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.
janzhanal

janzhanal

2019-01-08 12:31

reporter   ~0033536

Hello,
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)
carwyn

carwyn

2019-01-09 17:40

reporter   ~0033548

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:

[global]
           ...
           idmap config * : backend = sss

So if simply starting winbind hasn't worked for you, are you using SSSD?
janzhanal

janzhanal

2019-01-10 09:38

reporter   ~0033553

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...
carwyn

carwyn

2019-01-10 18:21

reporter   ~0033560

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.
carwyn

carwyn

2019-01-14 11:36

reporter   ~0033578

These two sssd-users threads have more information on possible ways to get SSSD and Samba to co-exist:

https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/ACEUWJTGJUWUUD32EBN2I7PXIVZD3PTM/

https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/HSOPA6J7AKUFHPLM2MA6T3P3SJN7TFNW/
ywfn

ywfn

2019-03-07 09:30

reporter   ~0033956

In case it helps anyone else: looks like this new version of Samba has broken the "security = domain" mode. We were still using it just to keep things simple, even though we have AD (Win2016 DC's). Saw mention of it being broken now on the Samba mailing list as well. Had to switch over to "security = ads" mode to get things working again. (In addition to now running winbind, as the new version requires.)
jmhunter

jmhunter

2019-07-23 11:32

reporter   ~0034868

I got hit by this, too.

In my case I had to make a number of changes, here is the full list which should hopefully help others with the same issue! I ended up making liberal use of "-d 4" and got some good clues from this thread as well as other hits via google :)

My setup was fully working until the samba upgrade, but is now working again.


# yum install samba-winbind samba-winbind-clients
# systemctl enable winbind


In smb.conf I had to change
        realm = MYDOMAIN
to
        realm = MYDOMAIN.ORG.UK
and add (this works for my use case - others might vary)
        winbind use default domain = yes
        winbind enum groups = yes
        winbind nss info = rfc2307



In /etc/krb5.conf I needed to add the following lines to the [libdefaults] section:
 default_realm=MYDOMAIN.ORG.UK
 dns_lookup_kds=true


Then of course
# service winbind start
# service smb restart

I still have sssd enabled for unix logons, but my Samba shares now work again.



I am adding some error messages from my scrollback buffer that I encountered along the way, in case others search via google and have the same issues:

# net ads info -d 4
[...]
ads_find_dc: failed to find a valid DC on our site (MySite), Trying to find another DC for realm 'MYDOMAIN' (domain 'MYDOMAIN')
get_dc_list: preferred server list: ", *"
dns_send_req: Failed to resolve _ldap._tcp.dc._msdcs.MYDOMAIN (Success)
ads_dns_lookup_srv: Failed to send DNS query (NT_STATUS_UNSUCCESSFUL)
get_dc_list: no servers found
ads_find_dc: falling back to netbios name resolution for domain 'MYDOMAIN' (realm 'MYDOMAIN')
get_dc_list: preferred server list: ", *"
[...]
ads_find_dc: name resolution for realm 'MYDOMAIN' (domain 'MYDOMAIN') failed: NT_STATUS_NO_LOGON_SERVERS
ads_connect: No logon servers are currently available to service the logon request.
(this was resolved by editing realm in smb.conf - I think the DNS lookup should have been for the FQDN instead)

# wbinfo -P
checking the NETLOGON for domain[MYDOMAIN] dc connection to "" failed
wbcPingDc2(MYDOMAIN): error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233)
(this was resolved by editing realm in smb.conf)

# wbinfo -t
checking the trust secret for domain MYDOMAIN via RPC calls failed
wbcCheckTrustCredentials(MYDOMAIN): error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233)
failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR
Could not check secret
(this was resolved by editing realm in smb.conf)


# wbinfo -P
checking the NETLOGON for domain[MYDOMAIN] dc connection to "dc1.mydomain.org.uk" succeeded
# wbinfo -i myusername
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
(this seemed to be an unusual combination of errors but was finally resolved via krb5.conf once I figured out that needed to be set, too)
TrevorH

TrevorH

2019-07-23 11:44

manager   ~0034869

Since this change has come about as a result of a Redhat change upstream and is working as designed, I am going to close this bug entry. It's not a bug.

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

Issue History

Date Modified Username Field Change
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:18 dijuremo@gmail.com Note Added: 0033338
2018-12-14 16:22 TrevorH Note Added: 0033339
2018-12-14 16:30 dijuremo@gmail.com 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
2019-03-07 09:30 ywfn Note Added: 0033956
2019-07-23 11:32 jmhunter Note Added: 0034868
2019-07-23 11:44 TrevorH Status new => closed
2019-07-23 11:44 TrevorH Resolution open => not fixable
2019-07-23 11:44 TrevorH Note Added: 0034869