update to samba 3.6.23-30 on RedHat server 6.7 breaks connections from clients on AD forest

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?

Solution 1:

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:

[2016/04/22 16:15:20.654780, 5] Auth/token_util.c:527(debug_unix_user_token)
UNIX token of user 1154
Primary group is 496 and contains 0 supplementary groups

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/echo

in /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:

[2016/04/22 16:21:20.996130, 5] auth/token_util.c:527(debug_unix_user_token)
UNIX token of user 1154
Primary group is 496 and contains 4 supplementary groups
[... list of the groups ...]

So to sum up:

• activate winbind to allow AD auth;

• add username map script = /bin/echo in the conf file.

I do not find this solution ideal but that could be a fix while waiting for something better.

Solution 2:

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.