Bug 1657428 - Window's client cannot connect samba-4.8.3-4 using hostname. IP connection works fine
Summary: Window's client cannot connect samba-4.8.3-4 using hostname. IP connection wo...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: samba
Version: 7.7
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Isaac Boukris
QA Contact: Andrej Dzilský
URL:
Whiteboard:
Depends On:
Blocks: 1763650
TreeView+ depends on / blocked
 
Reported: 2018-12-08 03:42 UTC by amitkuma
Modified: 2020-05-21 08:01 UTC (History)
29 users (show)

Fixed In Version: samba-4.10.4-7.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1763650 (view as bug list)
Environment:
Last Closed: 2020-03-31 19:56:34 UTC
Target Upstream Version:


Attachments (Terms of Use)
Level 10 log (1.03 MB, text/plain)
2019-04-05 20:46 UTC, Daniel Sartori
no flags Details
samba logs (139.06 KB, application/gzip)
2019-05-20 10:17 UTC, kludhwan
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:1084 None None None 2020-03-31 19:57:08 UTC
Samba Project 14106 None None None 2019-10-14 11:55:44 UTC

Comment 6 Andreas Schneider 2019-02-12 13:41:00 UTC
Closing as no details have been provided and the case is closed too.

Comment 7 Jarrod Igou 2019-02-12 15:01:57 UTC
Andreas, I'd be happy to provide additional details (as the owner of the case).

Please let me know what additional details you need.

Jarrod

Comment 8 MOM20xx 2019-02-14 20:15:38 UTC
Sorry we had this issue also.

our configuration:

machine is joined to active directory using realmd and sssd. winbind ist not used.

Samba configuration is used for guest sharing and acting as standalone server:

# Global parameters
[global]
	disable spoolss = Yes
	guest account = xxx
	load printers = No
	log file = /var/log/samba/log.%m
	map to guest = Bad User
	max log size = 50
	printcap name = /dev/null
	security = USER
	server string = Samba Server Version %v
	unix extensions = No
	workgroup = WORKGROUP
	idmap config * : backend = tdb


[batchxml]
	comment = Someshare
	create mask = 0640
	directory mask = 0750
	guest ok = Yes
	path = /home/xxx/input/batch_xml
	read only = No
	store dos attributes = Yes
	wide links = Yes


[rpd]
	comment = someothershare
	create mask = 0640
	directory mask = 0750
	guest ok = Yes
	path = /home/xxx/output/rpd
	read only = No
	store dos attributes = Yes
	wide links = Yes

this works fine with samba version 4.7.x but fails with actual samba version.

here some log details:

[2018/12/12 07:58:09.592549,  5, pid=26108, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:425(load_auth_module)
  load_auth_module: auth method sam_ignoredomain has a valid init
[2018/12/12 07:58:09.592626,  5, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec_start.c:739(gensec_start_mech)
  Starting GENSEC mechanism spnego
[2018/12/12 07:58:09.592690,  5, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec_start.c:739(gensec_start_mech)
  Starting GENSEC submechanism ntlmssp
[2018/12/12 07:58:09.592707,  2, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/ntlmssp/ntlmssp.c:119(gensec_ntlmssp_update_find)
  Failed to parse NTLMSSP packet: zero length
[2018/12/12 07:58:09.592716, 10, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec.c:440(gensec_update_send)
  gensec_update_send: ntlmssp[0x5570df8d99c0]: subreq: 0x5570df8d4630
[2018/12/12 07:58:09.592725, 10, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec.c:440(gensec_update_send)
  gensec_update_send: spnego[0x5570df8d8980]: subreq: 0x5570df8cfa10
[2018/12/12 07:58:09.592737,  5, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec.c:492(gensec_update_done)
  gensec_update_done: ntlmssp[0x5570df8d99c0]: NT_STATUS_INVALID_PARAMETER tevent_req[0x5570df8d4630/../auth/ntlmssp/ntlmssp.c:181]: state[3] error[-7963671676338569203 (0x917B5ACDC000000D)]  state[struct gensec_ntlmssp_update_state (0x5570df8d47c0)] timer[(nil)] finish[../auth/ntlmssp/ntlmssp.c:189]
[2018/12/12 07:58:09.592750,  1, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/spnego.c:1218(gensec_spnego_server_negTokenInit_step)
  gensec_spnego_server_negTokenInit_step: ntlmssp: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_INVALID_PARAMETER
[2018/12/12 07:58:09.592762,  5, pid=26108, effective(0, 0), real(0, 0), class=auth] ../auth/gensec/gensec.c:492(gensec_update_done)
  gensec_update_done: spnego[0x5570df8d8980]: NT_STATUS_INVALID_PARAMETER tevent_req[0x5570df8cfa10/../auth/gensec/spnego.c:1601]: state[3] error[-7963671676338569203 (0x917B5ACDC000000D)]  state[struct gensec_spnego_update_state (0x5570df8cfba0)] timer[(nil)] finish[../auth/gensec/spnego.c:1993]
[2018/12/12 07:58:09.593541,  5, pid=26108, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:524(make_auth3_context_for_ntlm)

Hope this is enough to fix this.
guest sharing is essential for us on this server. so we currently blocked actual samba packages until this will be fixed

Best Regards,
MOM20xx

Comment 9 Andreas Schneider 2019-02-18 11:04:57 UTC
I'm not able to reproduce this. It works for me.


Which Windows version is used here?
Is the user connecting an Active Directory user?
Is the user connecting using the IP address or the hostname?

Comment 10 MOM20xx 2019-02-18 11:59:42 UTC
don't work from windows 2003, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2016, Windows 7

works when using IP Adress

does not work when using hostname

User is AD User.

sharing should work as anonymous guest sharing. 

no account explicit defined in tdb 

just for info we are on centos but samba packages should be the same

Comment 11 Jarrod Igou 2019-02-19 21:40:15 UTC
For us, the only significant difference from comment 10 is that the user is a local account on the RHEL7 system, not an AD user.

We can add Windows10 to the list of OS that the mount doesn't work from.

As stated in my Support case:  If we try to connect via the hostname to Samba 4.8, it will not connect. If we use the IP address, we can connect.

Thanks--

Jarrod

Comment 15 Guilhem Eyraud 2019-03-27 18:03:06 UTC
Hi all,

We have the same issue here, do any of you found a solution ?

We use AD, IP connection is working but hostname fail.
This happened right after 4.8 update.

Thanks,

G

Comment 16 Andreas Schneider 2019-04-02 13:03:53 UTC
We need "log level = 10" debug log files reproducing the issue.

Comment 17 Daniel Sartori 2019-04-05 20:46:04 UTC
Created attachment 1552708 [details]
Level 10 log

Level 10 log as requested

Comment 18 kludhwan 2019-05-20 10:17:15 UTC
Created attachment 1571255 [details]
samba logs

One of my other cu is facing the same issue accessing from linux machine works fine.

I have downgraded the packages as workaround and that has fixed the issue.

Check log file log.10.148.134.19 and log.10.148.184.215

Comment 29 ludwig.fischer 2019-07-25 08:42:03 UTC
We are facing the same problem. Here IP and a host alias (cnmae) works fine, but not the real hostname. Windows10 clients are used.

Comment 30 Andreas Schneider 2019-08-06 14:31:59 UTC
Ludwig, can you provide log files reproducing the connection with a valid connect and a failing one. Corresponding network trace to the log files would be great.

More hints for debugging: https://hackmd.io/@asn/SkHk8rXBz

Comment 31 amitkuma 2019-08-09 08:00:50 UTC
@ludwig.fischer 
- Have you opened a support case with Red Hat?
- Have you attached the case to this Bugzilla?

Comment 32 Andreas Schneider 2019-08-09 15:26:14 UTC
Another question is, has the client been joined to AD using sssd?

Comment 34 Martin Angermeier 2019-08-13 06:43:36 UTC
We face the same issue....

At first we thought it would only occur in RHEL 7.6 with Samba 4.8.3 but at the moment we got it on RHEL 7.5 also. 

We join the client to AD using SSSSD here.

Our research so far:

- SSSD with Samba 4.8.3: NOT OK
- Winbind with Samba 4.8.3: OK
- SSSD with Samba 4.7.1-6: OK

Comment 35 Stuart 2019-08-14 16:57:41 UTC
I'm having the issue with 7.6, Samba 4.8.3 with the server being joined to the domain via winbind.

Comment 36 Isaac Boukris 2019-08-16 14:58:47 UTC
Could this be related to SMB1 vs SMB2 ? I found this seemingly related kb:
https://support.microsoft.com/hu-hu/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser

Comment 37 amitkuma 2019-08-20 08:01:53 UTC
But Isaac above article talks about no support for
Windows client cannot connect using guest account to remote server at all.

But in bugzilla customers are able to connect using IP address but not hostname.

Comment 38 Isaac Boukris 2019-08-20 10:08:29 UTC
The behaviour seen in the pcap (attached to samba bug) resembles the description in the article, that is a failed ntlm auth which is accepted as guest but then rejected by the client.
Perhaps the working connection uses smb1 somehow ? is there packet capture of working and non-working from the same machine to compare ?

Comment 39 amitkuma 2019-08-20 10:18:38 UTC
Hey Isaac.
Attached:
-> network_w_to_hostname.pcap : For WINDOWS Desktop NOT working  towards hostname
-> network_w_to_IP.pcap : For WINDOWS Desktop accessing successfully the share towards IP

Comment 44 Isaac Boukris 2019-08-28 09:53:28 UTC
Looking at 'network_w_to_hostname.pcap' I do see now kerberos being tried and then fails without falling back to ntlmssp. I'll try  to reproduce.

Comment 45 amitkuma 2019-08-30 12:21:48 UTC
(In reply to Isaac Boukris from comment #44)
> Looking at 'network_w_to_hostname.pcap' I do see now kerberos being tried
> and then fails without falling back to ntlmssp. I'll try  to reproduce.
Correct. This what i observed in packet capture.

But why at all kerberos auth is attempted, can we check by disabling kerberos auth on Window's client?
Are you able to repro?

Comment 46 Isaac Boukris 2019-09-02 09:12:08 UTC
The client would attempt kerberos when there is a registered SPN for the target FQDN.
I opened an upstream bug:
https://bugzilla.samba.org/show_bug.cgi?id=14106

Comment 52 Mihai B. 2019-10-09 07:30:44 UTC
I came across this issue after upgrading to samba-4.9.1-6 on Centos7. The issue occurs only if the user accessing the samba share is authenticated through AD. Local users (non AD) can still access the share using hostname. As an workaround I changed the security context of all backup jobs (scheduled tasks) from AD to local user.

Comment 55 Charles Zimmerman 2019-10-15 13:18:24 UTC
I have seen the same issue as well on CentOS 7. This was what I did to work around the issue:

Downgraded from Samba 4.9.1.6 to 4.7.1.6 (saw this on a forum post - don't have the link handy)
Created local user accounts for our critical service processes that match our AD accounts, setting the passwords the same
AD authentication kind of works? Our AD accounts that also have local accounts now connect to the share.

This obviously isn't a permanent solution since I do have same users that need to access the Samba shares that are a tiny bit inconvenienced right now. 

Here's another wrench that I wonder if any of you also have: We recently upgraded our domain controllers to Server 2016. We did not have this problem prior to that upgrade (unless we just had a Samba update install the same week we did the AD upgrade).

Comment 72 errata-xmlrpc 2020-03-31 19:56:34 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://access.redhat.com/errata/RHSA-2020:1084


Note You need to log in before you can comment on or make changes to this bug.