I have two TurnKey Linux Fileserver 13 (basically Debian 7.3) running Samba to share folders on our mostly-Windows LAN. Samba is configured to authenticate users using Active Directory on our domain controller.

This was all working great until recently, now both Samba servers fail to authenticate some users. Other users who have been using the servers can still connect and access files just fine (cached credentials?). The following is a typical example of what is logged in the Samba log on a failed login attempt:

[2016/04/26 20:08:15.768961,  0] rpc_client/cli_netlogon.c:459(rpccli_netlogon_sam_network_logon)
  rpccli_netlogon_sam_network_logon: credentials chain check failed
[2016/04/26 20:08:15.769053,  0] auth/auth_domain.c:331(domain_client_validate)
  domain_client_validate: unable to validate password for user lholdeman in domain meg to Domain controller DC01.MEG.LOCAL. Error was NT_STATUS_ACCESS_DENIED.

I don't know of anything that changed with our domain controller, and I'm fairly sure our domain controller is allowing Samba to connect to authenticate users as I did a quick setup in VirtualBox of the exact same OS/software, copied all my production configs over, and successfully logged into the temporary Samba setup using the same domain credentials that didn't work on the production machines.

Here's a copy of my Samba config as well:

    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    obey pam restrictions = yes
    admin users = root
    #read prediction = yes
    passwd program = /usr/bin/passwd %u
    dns proxy = no
    netbios name = PAFILES
    default = companyfiles
    workgroup = MEG
    os level = 20
    auto services = companyfiles
    security = ads
    delete user script = /usr/sbin/userdel -r '%u'
    max log size = 1000
    directory mode = 777
    log file = /var/log/samba/samba.log
    read raw = no
    guest account = nobody
    write raw = no
    add group script = /usr/sbin/groupadd '%g'
    socket options = TCP_NODELAY
    delete group script = /usr/sbin/groupdel '%g'
    add user to group script = /usr/sbin/usermod -G '%g' '%u'
    force directory mode = 777
    wins server = DC01.MEG.LOCAL
    #null passwords = yes
    encrypt passwords = true
    winbind trusted domains only = yes
    winbind use default domain = yes
    realm = MEG.LOCAL
    passdb backend = tdbsam
    unix extensions = no
    wide links = yes
    server string = TurnKey Linux FileServer
    password server = DC01.MEG.LOCAL
    unix password sync = yes
    force create mode = 777
    add user script = /usr/sbin/useradd -m '%u' -g users -G users
    syslog = 0
    create mode = 777
    panic action = /usr/share/samba/panic-action %d
    pam password change = yes

    shadow:basedir = /srv/storage
    force directory mode = 777
    recycle:keeptree = yes
    shadow:sort = desc
    vfs objects = shadow_copy2
    writeable = yes
    delete readonly = yes
    path = /srv/storage
    shadow:snapdir = ../snapshots/storage
    force create mode = 777
    comment = Public Share
    create mode = 0777
    recycle:repository = Recycle Bin
    recycle:versions = yes
    directory mode = 0777

Any ideas on what I might try next? Thanks!


There is an upstream bug in Samba that was included in the updates released on April 12 in response to the widely-publicized "Badlock" vulnerability, which results in exactly the behavior you are seeing. The Debian bug is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820981 Red Hat has a working patch, but has not yet released it as of today (Apr 27): https://bugzilla.redhat.com/show_bug.cgi?id=1326918

At the moment it looks like your only options are either to downgrade to the previous version of Samba, or wait for a patch from your distro.

  • The fix for this bug that seems to be working for me was to install and start winbind. Apparently this gives Samba an alternative way to do its thing instead of the now broken method used before. There's more info at the debian bug report linked above. – Nelson Hoover May 4 '16 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.