I have a Samba server (version 3.6.23-30) running on a RedHat Enterprise sever version 6.7. It is joined to Active Directory, and authentifies the users to AD. Winbind is not running ("Winbind is not used; users and groups are local" situation, according to the Samba howto). This worked perfectly since a long time, until the last update from samba 3.6.23-25 to 3.6.23-30 (actually several fixes for security issues, including Badlock, were introduced 10 days ago in 3.6.23-26, but that version was never deployed here).
I tried downgrading Samba to 3.6.23-25, and that solves the problem (but of course is not a solution, given the security fixes contained in 3.6.23-26):
yum downgrade samba-3.6.23-25.el6_7.x86_64 samba-common-3.6.23-25.el6_7 samba-winbind-clients-3.6.23-25.el6_7 samba-client-3.6.23-25.el6_7 samba-winbind-3.6.23-25.el6_7
After the installation of the update, users could not connect anymore to the shares on the server, directly getting an "Access denied" message:
C:\Users\admin>net use \\servername /user:INTRANET\username The password or user name is invalid for \\servername. Enter the password for 'INTRANET\username' to connect to 'servername': System error 5 has occurred. Access is denied.
This is not due to a wrong password or anything like that, because in that case, it displays error 1326 (username or password is incorrect). The connection has been tried from Windows 7, Windows Server 2012 R2, and even Windows XP SP3, with the same result.
net ads testjoin says that that server is correctly joined to Active Directory. I also tried leaving AD and rejoining it, but it didn't improve the situation.
The error message for the client in the smbd log (using a debug log level) is:
[2016/04/18 14:09:19.133618, 2] ../libcli/auth/credentials.c:289(netlogon_creds_client_check) credentials check failed [2016/04/18 14:09:19.133674, 0] rpc_client/cli_netlogon.c:623(rpccli_netlogon_sam_network_logon) rpccli_netlogon_sam_network_logon: credentials chain check failed [2016/04/18 14:09:19.134036, 0] auth/auth_domain.c:331(domain_client_validate) domain_client_validate: unable to validate password for user username in domain INTRANET to Domain controller AD6. Error was NT_STATUS_ACCESS_DENIED. [2016/04/18 14:09:19.135842, 5] auth/auth.c:281(check_ntlm_password) check_ntlm_password: winbind authentication for user [username] FAILED with error NT_STATUS_ACCESS_DENIED [2016/04/18 14:09:19.135917, 2] auth/auth.c:330(check_ntlm_password) check_ntlm_password: Authentication for user [username] -> [username] FAILED with error NT_STATUS_ACCESS_DENIED
Now, if I start the winbind daemon, the authentication problem disappears and users could successfully connect to the Samba server. However, in that case a second annoying problem appears. Taking a directory where a user only has rights because of the group membership (i.e. user is member of a UNIX group on the Samba server):
username$ ls -l /export/projects/testproject drwxrws---. 2 root testgrp 4096 Apr 18 11:24 testproject
username is member of the
testgrp group and can successfully access the directory:
username$ ls -l /export/projects/testproject/ -rw-r--r--. 1 root testgrp 0 Apr 18 11:24 test.txt
The same user connected to the Samba server could not access the directory (access denied). Before the update (with
winbindd disabled), the access worked fine. I guess this has something to do with the fact that
winbindd is running, as the
testgrp group does not map to any AD object (it is displayed in the Security tab of the Windows Explorer as UNIX group\testgrp).
Is there any way to be able to use local groups as here with winbind enabled (and without the need of creating corresponding AD objects)? I tried adding this to smbd.conf:
idmap config * : backend = tdb idmap config * : range = 1000000-1999999
but it does not improve anything, also because I guess this is rather mapping AD users/groups to Linux ones, rather than the opposite.
Or in alternative, what could be the "access denied" problem when running Samba without
winbindd? Is that a bug introduced by the update (and therefore should be sent as a bug report to RedHat), or rather a feature due to some change in the security model?