View Issue Details

IDProjectCategoryView StatusLast Update
0015525CentOS-7sambapublic2019-07-23 11:44
Reporterrsandu Assigned To 
Status closedResolutionnot fixable 
Platformx86_64OSCentOSOS Version7.6.1810 (Core)
Summary0015525: 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
"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,
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.




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


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.


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.


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.


2018-12-14 09:33

reporter   ~0033335

 I have the same problem. on Windows 10 and with smbclient if I do not give the -W <WORKGROUP> option.

Will try to install the rpm from CentOS 7.5 to fix it


2018-12-14 11:15

reporter   ~0033337

After installing samba-winbind
systemctl start winbind

all works - now it looks good

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:

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.


2018-12-14 16:22

manager   ~0033339

Please note the following entry in the upstream RHEL 7.6 Release Notes:

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.

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.


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


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.


2019-01-08 12:31

reporter   ~0033536

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... (1,830,823 bytes)
smb.conf (2,395 bytes)   
    workgroup = INVASYS
    realm = INVASYS.ORG

    security = ads
    kerberos method = secrets and keytab

    client ipc signing = mandatory
    client ldap sasl wrapping = seal
    client signing = mandatory
    client use spnego = yes

    server signing = mandatory
    smb encrypt = auto

log level = 3 

    idmap config * : backend = sss
    idmap config * : range   = 200000-2147483647

    map acl inherit = yes
    store dos attributes = yes
    vfs objects = acl_xattr

    hide special files = yes
    hide unreadable = yes

    # Disable annoying MAC custom files
    delete veto files = yes
    veto files = /.DS_Store/._*/

    comment = File share for Accounting, HR and similar purposes
    path = /share/accounting
    valid users =  +"ceo" +"ceor" +"coo" +"export manager" +"it manager" +"marketing" +"office manager" +"qa" +"r&d manager"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for HR
    path = /share/departments/hr
    valid users =  +"ceo" +"ceor" +"coo" +"hr" +"office manager" +"tl"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for IT Department
    path = /share/departments/it
    valid users =  +"it"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for Malware Department
    path = /share/departments/malware
    valid users =  +"malware"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for Management
    path = /share/management
    valid users =  +"ceo" +"ceor" +"coo"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for Projects
    path = /share/projects
    valid users =  +"all"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for public usage
    path = /share/public
    valid users =  +"all"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for Science Department
    path = /share/departments/science
    valid users =  +"science" +"cto"
    browsable = yes
    guest ok = no
    writable = yes

    comment = File share for Security Department
    path = /share/departments/security
    valid users =  +"cto" +"it" +"management" +"security"
    browsable = yes
    guest ok = no
    writable = yes
smb.conf (2,395 bytes)   
sssd.conf (1,246 bytes)   
config_file_version = 2
domains =
services = nss, pam, pac

# Serious failures. An error announcing that a particular
# request or operation has failed.
debug_level = 0x0070

fallback_homedir = /home/%d/%u
default_shell = /bin/bash


cache_credentials = false
# Enumerate doesn't work for more users - it ends in timeouts
enumerate = true
debug_level = 6

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

ad_domain =
ad_gpo_access_control = permissive
ad_server =,

dyndns_update = false
dns_discovery_domain =

ldap_schema = ad
ldap_id_mapping = true
ldap_idmap_default_domain_sid = S-1-5-21-3784930729-2365486616-1008349783
ldap_referrals = false

ldap_user_search_base = OU=Accounts,OU=IdM,OU=Auth,DC=invasys,DC=org?subtree?(&(objectClass=user))
ldap_group_search_base = CN=Users,DC=invasys,DC=org?onelevel?(&(objectClass=group)(CN=Domain Users))?OU=Groups,OU=IdM,OU=Auth,DC=invasys,DC=org?subtree?(objectClass=group)

ad_access_filter =!(userAccountControl:1.2.840.113556.1.4.803:=2))(memberOf:1.2.840.113556.1.4.1941:=CN=Linux Server Admins,OU=Roles,OU=Groups,OU=IdM,OU=Auth,DC=invasys,DC=org))
sssd.conf (1,246 bytes)   


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/ 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?


2019-01-10 09:38

reporter   ~0033553

I would say the guide was updated recnetly:

Otherwise sssd is exactly what we have in place...


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.


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:


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


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
        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:

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 "" 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)


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:

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 Note Added: 0033338
2018-12-14 16:22 TrevorH Note Added: 0033339
2018-12-14 16:30 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:
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