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:
[global]
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
[companyfiles]
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!
Best Answer
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.