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'm having the same issue. If you find the answer please post it for us.
    – Jeight
    Apr 18, 2016 at 20:02
  • Perhaps related to this issue: bugzilla.redhat.com/show_bug.cgi?id=1327697 -- in that case I hope the next update of the samba packages will solve the problem.
    – Ale
    Apr 19, 2016 at 7:17

4 Answers 4


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.

  • just re-updated to the buggy version, and added the username map script, it definitely works around the problem using samba with local groups on AD when winbindd is enabled.
    – Ale
    Apr 28, 2016 at 16:43

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.

  • windbindd plus the username map script trick proposed by Tabs (serverfault.com/a/772263/217522) could also be a possibility if downgrading is not an option -- I downgraded so didn't test whether this works but it seems promising
    – Ale
    Apr 27, 2016 at 23:10

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

  • Interesting! Unfortunately I don't have a dev server on hand where I can keep the buggy version running, so I can't replicate this without breaking again our real server. I hope that this bug gets patched soon!
    – Ale
    Apr 20, 2016 at 7:07

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 winbindd and setting a username map script = /bin/echo directive in the config file) was working perfectly. Now, the recently updated package (samba-3.6.23-35) fixes the bug, rendering the workaround unnecessary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.