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
Here, 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?
I faced the same problem: AD authentication without winbind was broken for me.
The reason why I stopped winbind originally was because it could not find the local groups (although it seems to find the correct user mapping). Here is a log excerpt with winbind activated:
As you can see the user ID is correct (1154) but the groups are not found except the primary one (which is correct too).
It seems I found a solution to correct that problem: You should add the option
username map script = /bin/echoin /etc/smb.conf. This solution was proposed here: http://samba.2283325.n4.nabble.com/samba-winbind-ignores-local-unix-groups-td3410748.html, but not tested.
As I understood from the man pages, this option forces a different mapping after AD authentication. Using the echo command just map the name to itself so it should work when ever the local username is the same than the AD username. The result is the following:
So to sum up:
activate winbind to allow AD auth;
add
username map script = /bin/echoin the conf file.I do not find this solution ideal but that could be a fix while waiting for something better.
Yes, this is an upstream Samba bug, which was introduced to RHEL users in the latest Samba package updates. Red Hat is aware of the problem, and has a candidate patch to fix it, but as of today (Apr 27) has not yet released an update with the patch. See https://bugzilla.redhat.com/show_bug.cgi?id=1326918 and https://bugzilla.redhat.com/show_bug.cgi?id=1327697 to watch for updates on this.
In the meantime, some users may be able to run winbindd as a work-around if their configuration permits it; otherwise downgrading to the previous release as you have done is the only other option.
So, this may not be the right place to put this, but I do not have the reputation points to comment. I am also having this issue with Scientific Linux 6.7 and upgraded last Wednesday across our systems. I found that the problem lies in the netbios name resolution (nmb). If the user specifies the fully qualified domain name of the active directory, they are granted access, otherwise if they use the netbios name of the domain, I will see the "NT_STATUS_ACCESS_DENIED" message.
I also found that domain joined windows boxes are able to access the samba shares, but I believe that is because they have a current kerberos token.
Update: I found that specifying the fully qualified domain name was actually engaging in a kerberos ticket and granting access, I found on an ubuntu machine that installing krb5-user allowed nautilus to get a kerberos ticket, and then allow access (it was not working without it), so I suppose that is the piece that apple/mac clients and Windows clients were doing that I did not notice yet..
While this is not the answer, I hope it helps. Respectfully, -Glen
As stated in several of the answers and comments, this was indeed a bug in the Samba package after the inclusion of the Badlock fixes. As a temporary workaround, the solution provided by Tabs (using
winbinddand setting ausername map script = /bin/echodirective in the config file) was working perfectly. Now, the recently updated package (samba-3.6.23-35) fixes the bug, rendering the workaround unnecessary.