RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1202347 - Can no longer connect to samba4 shares not in AD domain
Summary: Can no longer connect to samba4 shares not in AD domain
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: samba
Version: 7.1
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Guenther Deschner
QA Contact: Robin Hack
URL:
Whiteboard:
Depends On:
Blocks: 1258317
TreeView+ depends on / blocked
 
Reported: 2015-03-16 12:54 UTC by Sten Sletbak
Modified: 2019-10-10 09:41 UTC (History)
25 users (show)

Fixed In Version: samba-4.1.12-22.el7
Doc Type: Bug Fix
Doc Text:
When running Samba without the winbindd service, authentication with user name and password sometimes failed. Now, it is possible to run Samba without winbindd, although it is not recommended.
Clone Of:
: 1233295 1258317 (view as bug list)
Environment:
Last Closed: 2015-11-19 09:11:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Config and log files (166.21 KB, application/octet-stream)
2015-03-16 14:08 UTC, Sten Sletbak 		no flags Details
Samba logs (98.90 KB, application/octet-stream)
2015-03-17 16:38 UTC, Sten Sletbak 		no flags Details
Core Dump info from /var/log/messages on problem server (5.11 KB, text/plain)
2015-03-24 15:55 UTC, Garrett 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1534003 0 None None None Never
Red Hat Product Errata RHBA-2015:2258 0 normal SHIPPED_LIVE samba bug fix and enhancement update 2015-11-19 09:22:47 UTC

Description Sten Sletbak 2015-03-16 12:54:14 UTC 
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.
Comment 2 Sumit Bose 2015-03-16 13:05:59 UTC 
Can you check with 

rpm -qi sssd-libwbclient

if a package called sssd-libwbclient is installed? If yes, please remove it and try again.
Comment 3 Sten Sletbak 2015-03-16 13:09:19 UTC 

# rpm -qi sssd-libwbclient
package sssd-libwbclient is not installed
Comment 4 Sumit Bose 2015-03-16 13:15:28 UTC 
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.
Comment 5 Sten Sletbak 2015-03-16 13:28:28 UTC 
Do you want any specific log levels to the smb, sssd and smbclient logs?
Comment 6 Sten Sletbak 2015-03-16 14:08:56 UTC 
Created attachment 1002287 [details]
Config and log files
Comment 7 Andreas Schneider 2015-03-16 15:17:36 UTC 
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 ...
Comment 8 Sten Sletbak 2015-03-16 15:50:51 UTC 
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.
Comment 9 Sumit Bose 2015-03-16 16:21:44 UTC 
SSSD only supports Kerberos auth. Please try to start winbind so that Samba can use winbind for NTLM.
Comment 10 Sten Sletbak 2015-03-16 16:41:18 UTC 
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?
Comment 11 Sumit Bose 2015-03-16 16:47:53 UTC 
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?
Comment 12 Sten Sletbak 2015-03-16 18:05:45 UTC 
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.
Comment 13 Sumit Bose 2015-03-17 15:59:15 UTC 
Can you sent the samba logs form RHEL-7.0 as well?
Comment 14 Sten Sletbak 2015-03-17 16:38:02 UTC 
Created attachment 1002868 [details]
Samba logs

smbclient //rh7-smb/stens -U stens -W ADA
Comment 15 Garrett 2015-03-24 15:51:46 UTC 
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.
Comment 16 Garrett 2015-03-24 15:55:51 UTC 
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.
Comment 18 MOM20xx 2015-04-27 17:36:35 UTC 
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
Comment 23 David Mansfield 2015-06-18 14:25:25 UTC 
Seems to affect latest Fedora packages as well.  Should I open a new bug?
Comment 24 Guenther Deschner 2015-06-18 14:37:41 UTC 
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!
Comment 25 David Mansfield 2015-06-18 15:45:56 UTC 
I put in bug#1233295
Comment 30 Andreas Schneider 2015-08-03 11:40:15 UTC 
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 ...
Comment 31 Richard Blocker 2015-08-17 17:25:42 UTC 
(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?
Comment 40 errata-xmlrpc 2015-11-19 09:11:16 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.