У меня есть два TurnKey Linux Fileserver 13 (в основном Debian 7.3), на которых работает Samba, для совместного использования папок в нашей локальной сети, в основном Windows. Samba настроена для аутентификации пользователей с помощью Active Directory на нашем контроллере домена.
До недавнего времени все это работало отлично, теперь оба сервера Samba не могут аутентифицировать некоторых пользователей. Другие пользователи, которые использовали серверы, по-прежнему могут без проблем подключаться и получать доступ к файлам (кэшированные учетные данные?). Ниже приводится типичный пример того, что регистрируется в журнале Samba при неудачной попытке входа в систему:
[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.
Я не знаю ничего, что изменилось в нашем контроллере домена, и я почти уверен, что наш контроллер домена позволяет Samba подключаться для аутентификации пользователей, поскольку я быстро установил в VirtualBox ту же ОС / программное обеспечение, скопировал все мои производственные конфигурации и успешно вошли во временную установку Samba, используя те же учетные данные домена, которые не работали на производственных машинах.
Вот и копия моей конфигурации Samba:
[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
Есть идеи, что я могу попробовать дальше? Спасибо!
В Samba есть ошибка восходящего направления, которая была включена в обновления, выпущенные 12 апреля в ответ на широко разрекламированную уязвимость «Badlock», которая приводит к именно тому поведению, которое вы наблюдаете. Ошибка Debian здесь: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820981 Red Hat имеет рабочий патч, но на сегодняшний день (27 апреля) он еще не выпущен: https://bugzilla.redhat.com/show_bug.cgi?id=1326918
На данный момент похоже, что у вас есть единственные варианты: либо перейти на предыдущую версию Samba, либо дождаться патча от вашего дистрибутива.