Closing as no details have been provided and the case is closed too.

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

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

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?

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

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

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

We need "log level = 10" debug log files reproducing the issue.

Created attachment 1552708 [details]
Level 10 log

Level 10 log as requested

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

We are facing the same problem. Here IP and a host alias (cnmae) works fine, but not the real hostname. Windows10 clients are used.

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

@ludwig.fischer 
- Have you opened a support case with Red Hat?
- Have you attached the case to this Bugzilla?

Another question is, has the client been joined to AD using sssd?

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

I'm having the issue with 7.6, Samba 4.8.3 with the server being joined to the domain via winbind.

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

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.

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 ?

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

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.

(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?

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

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.

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).

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