Windows 10 and Server 2016 clients block access to (Samba) shares with public guest account: Technical analysis and workaround for event 31017

Written by - 0 comments

Published on July 22nd 2019 - Listed in Windows Linux Security


Everyone knows how easy it is to access public network shares from a Windows client. Simply enter \\SERVERNAME (or \\SERVER.IP.ADDRESS) in the Windows Explorer and a list of shares appears. Or... they should.

But something has changed in Windows 10 and Windows Server 2016 clients. Suddenly public shares using a guest account will not show up anymore. In Windows Explorer the following error message shows up:

Note: The screenshot is in German. Translated to English:

Windows cannot access "\\twwfs011". Check the spelling of the name and try again.

What happened?!

Accessing a public share with a guest access means no authentication. So everyone with network access to the share is able to access data from it. Depending on the share's configuration even write to it. This is of course handy as a user doesn't have to enter some credentials he already had forgotten a while ago. But convenience always breaks security. A couple of years ago, an exploit of the SMB1 protocol, called EternalBlue, was released. This vulnerability opened the door to the probably best known Ransomeware: WannaCry. It infected a computer, searched for SMB1 and open (public) network shares without authentication and placed or even installed itself on the server hosting the network share, too.

Microsoft decided to close these doors by disabling SMB1 (CIFS) file sharing support and by disabling the guest access to network shares.

Analyzing access from Windows 10 client

As mentioned above, the error message shown in Windows Explorer is not helpful at all; it suggests that the server could not be found. However a closer look into the Event Log of the SMBClient Windows application reveals more. An event with ID 31017 was logged and contained the following description:

This event indicates that the server tried to log on the user as an unauthenticated guest but was denied by the client. Guest logons do not support standard security features such as signing and encryption. Therefore, guest logons are vulnerable to man-in-the-middle attacks that can expose sensitive data on the network. Windows disables "insecure" (nonsecure) guest logons by default. Microsoft recommends that you do not enable insecure guest logons.

OK this event now gives us relevant information but technically we're non the wiser. Let's dig into the Samba logs.

Enabling Samba debug logging

To be able to see the communication between the Windows 10 client and our public Samba share, debug logging was enabled. Samba allows to define per client logging, so I prepared a config file with debug 3 (that's sufficient to log authentication problems):

root@sambaserver:~# cat /etc/samba/smb.conf.client-debug
[global]
# no log file size limitation
max log size = 0
# specific log file name
log file = /var/log/samba/log.%I
# set the debug level
log level = 3
# add the pid to the log
debug pid = yes
# add the uid to the log
debug uid = yes
# add the debug class to the log
debug class = yes
# add microsecond resolution to timestamp
debug hires timestamp = yes

Using this prepared config, a simple symlink with the client's IP address can be created. For example if you connect to the SMB share from a client with IP 172.30.123.195:

root@sambaserver:~# ln -s /etc/samba/smb.conf.client-debug /etc/samba/smb.conf.client-172.30.123.195

Now don't forget to tell Samba about the external config file(s) for client specific logging. In the [global] section (= before the definition of shares) of /etc/samba/smb.conf add:

include = /etc/samba/smb.conf.client-%I

Trying the same share access again from our Windows 10 client, Samba spits out a log of lines:

root@sambaserver:~# tail -f /var/log/samba/log.172.30.123.195
[...]
[2019/07/18 13:44:58.071184,  3, pid=32345, effective(0, 0), real(0, 0)] ../source3/param/loadparm.c:1609(lp_add_ipc)
  adding IPC service
[2019/07/18 13:44:58.071208,  3, pid=32345, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:189(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [DOMAIN]\[claudiokuenzler]@[WM2674] with the new password interface
[2019/07/18 13:44:58.071230,  3, pid=32345, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:192(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [DOMAIN]\[claudiokuenzler]@[WM2674]
[2019/07/18 13:44:58.071277,  3, pid=32345, effective(0, 0), real(0, 0), class=auth] ../source3/auth/check_samsec.c:399(check_sam_security)
  check_sam_security: Couldn't find user 'claudiokuenzler' in passdb.
[2019/07/18 13:44:58.071301,  2, pid=32345, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:332(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [claudiokuenzler] -> [claudiokuenzler] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2019/07/18 13:44:58.071351,  2, pid=32345, effective(0, 0), real(0, 0)] ../auth/auth_log.c:760(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [DOMAIN]\[claudiokuenzler] at [Thu, 18 Jul 2019 13:44:58.071341 CEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [WM2674] remote host [ipv4:172.30.123.195:65168] mapped to [DOMAIN]\[claudiokuenzler]. local host [ipv4:10.130.136.38:445]
[2019/07/18 13:44:58.071481,  2, pid=32345, effective(0, 0), real(0, 0)] ../auth/auth_log.c:220(log_json)
  JSON Authentication: {"timestamp": "2019-07-18T13:44:58.071393+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 0}, "status": "NT_STATUS_NO_SUCH_USER", "localAddress": "ipv4:10.130.136.38:445", "remoteAddress": "ipv4:172.30.123.195:65168", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "DOMAIN", "clientAccount": "claudiokuenzler", "workstation": "WM2674", "becameAccount": null, "becameDomain": null, "becameSid": "(NULL SID)", "mappedAccount": "claudiokuenzler", "mappedDomain": "DOMAIN", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": "(NULL SID)", "passwordType": "NTLMv2"}}
[2019/07/18 13:44:58.071506,  3, pid=32345, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_util.c:1626(do_map_to_guest_server_info)
  No such user claudiokuenzler [DOMAIN] - using guest account
[2019/07/18 13:44:58.079573,  3, pid=32345, effective(0, 0), real(0, 0)] ../source3/smbd/server_exit.c:244(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)

From this information we can see that:

  • Windows client submitted the logged in Windows user (claudiokuenzler) and the domain (DOMAIN) to Samba
  • Samba was unable to find the local user claudiokuenzler and DOMAIN\claudiokuenzler
  • Because this Samba server has map to guest = bad user configured, Samba now tells the client to "using guest account"
  • This is the moment when Windows chokes and leaves the party

How did it look with Windows 7?

[this article is still in progress. please come back later]











More recent articles: