Red Hat Bugzilla – Bug 1202347
Can no longer connect to samba4 shares not in AD domain
Last modified: 2015-11-19 04:11:16 EST
Description of problem: Computers not in AD can no longer connect to a samba4 domain member server with ldap authentication. Version-Release number of selected component (if applicable): samba-4.1.12-21.el7_1.x86_64 How reproducible: Always Steps to Reproduce: 1. smbclient //server/share -U user -W DOMAIN 3. Actual results: NT_STATUS_INVALID_COMPUTER_NAME or NT_STATUS_LOCK_NOT_GRANTED. Expected results: Normal smbclient session Additional info: Kerberos works, but requires that client computers be set up with a valid kerberos configuration of course. This problem applies to Windows and OSX computers not in the AD domain. Customers can no longer map a share as they could before the upgrade from RHEL 7.0 to RHEL 7.1.
Can you check with rpm -qi sssd-libwbclient if a package called sssd-libwbclient is installed? If yes, please remove it and try again.
# rpm -qi sssd-libwbclient package sssd-libwbclient is not installed
ok, thank you, Can you add your config and log files to the ticket as described on https://www.samba.org/~asn/reporting_samba_bugs.txt.
Do you want any specific log levels to the smb, sssd and smbclient logs?
Created attachment 1002287 [details] Config and log files
I'm sorry but you do not give detailed information. I assume the user ADA\stens wants to log in. As this is a domain user we need to lookup the user from AD using winbind but: check_winbind_security: wbcAuthenticateUserEx failed: WBC_ERR_WINBIND_NOT_AVAILABLE There is no winbind running ...
Ah, sorry, yes, ADA\stens is the relevant user in the logs. The logs are from a non production server that's joined to the ADA domain. We're using sss to lookup users in AD, not winbind. Logs from sssd should be included in the attached tarball (1002287). Do you need any other logs and/or debug levels? Just to clarify: I can reach the share from a Windows box joined to the domain and with smbclient -k //nhb/stens, but not from machines that are not domain members and does not have an ADA kerberos setup.
SSSD only supports Kerberos auth. Please try to start winbind so that Samba can use winbind for NTLM.
Thanks, it worked! :-) Testet with smbclient //nhb/stens -U stens -W ADA and from an OSX machine. I gather this is due to a change in sssd with the release of RHEL 7.1? No problems involved in running both sssd and winbind?
SSSD never supported NTLM which is the only authentication method for clients not joined to a domain. So you say it worked with RHEL-7.0 without running winbind?
Yup, just tried with the RHEL-7.0 template VM. The issue started after the upgrade to RHEL-7.1. winbind isn't even installed on these servers.
Can you sent the samba logs form RHEL-7.0 as well?
Created attachment 1002868 [details] Samba logs smbclient //rh7-smb/stens -U stens -W ADA
We are seeing a similar issue after having moved to samba 4.1.12-21, we don't rely on sssd or winbind in our configuration. If this should go in a separate bug report please let me know. Or setup involves using kinit and net ads join to get the basic authentication steps working for samba, and falling back on local system uid/gid sets for ownership of files. Similar to above winbind is not even installed on the machines in question. Samba security is set to 'ADS'. We started seeing the following errors a few days ago after 4.1.12-21 was applied: Mar 23 18:06:16 xxxx smbd[14936]: [2015/03/23 18:06:16.524510, 0] ../source3/auth/auth_domain.c:302(domain_client_validate) Mar 23 18:06:16 xxxx smbd[14936]: domain_client_validate: unable to validate password for user xxxx in domain xxxxxxx to Domain controller PDOM2.xx.xx.xxxxxxxx.xxx. Error was NT_STATUS_INVALID_COMPUTER_NAME. These persist over rejoins of the domain and do not crop up in all circumstances. As of right now a windows machine (non domain member) can connect via the standard domain name + username + pw combo, linux machines appear to be causing the server to generate core dumps (tested on fully patched fedora 20 and centos7.1), and OSX clients can only connect if they insert the realm name for the AD servers in instead of the domain name. Previous to -21, all three client types could connect with default arguments by supplying their AD username, password and the AD domain.
Created attachment 1005911 [details] Core Dump info from /var/log/messages on problem server This is a copy of the smbd output into /var/log/messages from a linux client attempting to connect to our samba 4.1.12-21 server with standard options, supplying domain/username/password.
Issue is also present in CentOS 71. In CentOS 7.1 the issue is fixed when building the spec file from 4.1.12-21 without patches 100 and patch 101 patch100 samba-4.2.x-fix_gecos_field_with_samlogon.patch patch101 samba-4.2.x-fix_net_rpc_join_schannel.patch according to https://lists.samba.org/archive/samba/2015-April/191212.html patch100 seems to break everything here. maybe patch101 has nothing to do with that issue but i removed it because the rpm will not build when patch100 is removed and patch101 should be applied. hopefully this will help you to fix this issue. best regards, mom20xx
Seems to affect latest Fedora packages as well. Should I open a new bug?
Fedora22 has the fix already that was still missing RHEL. If you're seeing the same issue there, it will likely have a different cause, but please: yes, open a new bug for it. Thanks!
I put in bug#1233295
This bug will be released with RHEL 7.2. If you need a z-stream release, you should look up the process how to request one ...
(In reply to Andreas Schneider from comment #30) > This bug will be released with RHEL 7.2. If you need a z-stream release, you > should look up the process how to request one ... Any particular reason why this won't be released before 7.2? Does that mean 7.2 is just around the corner? Any idea when?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2258.html