11

I’ve just set up a new Ubuntu 18.10 server with a single SMB share which I’d like to access from Windows. But whenever I try to open the paths \\servername or \\servername\sharename in Windows, I get this error message:

You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.

This is documented by Microsoft at Guest access in SMB2 disabled by default in Windows 10, Windows Server 2016 version 1709, and Windows Server 2019. If I use the Enable insecure guest logons group policy option, as suggested in the documentation, everything works fine. I can browse \\servername without entering any credentials, and if I try to access \\servername\sharename, I’m asked for a username and password. My Samba credentials work as expected.

But I don’t want to enable anything insecure! I’ve tried to disable all the default shares that are guest-accessible, and I’m happy to give up the ability to be able to browse \\servername (although it would be nice to have). I don’t need to support any legacy clients; I just want to access the share from one Windows 10 machine with a username and password.

Noting that the error message refers to SMB2, I tried adding the line server min protocol = SMB3 to /etc/samba/smb.conf in the [global] section, but this didn’t change anything.

How can I configure Samba so that Windows 10 will prompt the user for credentials, rather than attempting to use an insecure guest logon?

sjy
  • 211
  • 1
  • 2
  • 4

1 Answers1

12

After many hours of searching and cursing, I have the answer, at least for a domain/Active Directory environment.

The key point is to remove/comment out any map to guest line in your smb.conf (or set it to the default of never.) This disables unauthenticated user access which will make newer Windows happy.

But it creates the problem where machine accounts can't access the share in the event you're hosting software installation files there for deployment via GPO. To fix that, you need to add a linux account for the computer account ("COMPUTER$") and you need some kind of identity mapping (idmap) set up to ensure that computer account Kerberos principal ("DOMAIN\COMPUTER$") is matched to the UID of this new COMPUTER$ linux account.

Then of course the share itself needs to grant permissions to computer accounts. World-readable should suffice, but I ended up setting Samba to use Windows ACLs for shares as described (very well!) on the Samba wiki.

But if your Samba machine isn't completely/correctly integrated into the domain, that's much easier said than done. In my case, since my Samba configuration was originally set up in the 3.x days, it needed an overhaul. I ended up saving off the existing smb.conf, removing the machine from the domain, purging all Samba config files/packages, reinstalling the packages (on Debian, I needed samba, samba-vfs-modules and libnss-winbind,) configuring afresh as a domain member according to this Samba wiki page (I used Idmap ad FWIW), then setting ownership of the share target directories on the Samba box as described in the above Windows ACL article before I could set NTFS and share permissions in Computer Management. (Make sure the domain user you will use to manage permissions on the files in the share is either the owner of the files or a member of the group that does at the UNIX level.)

After all of that, testing from a Windows box using psexec.exe -i -s -d cmd.exe then issuing net use \\server\share /user:%COMPUTERNAME%$ no longer results in the dreaded error message but instead the very welcome The command completed successfully. And sure enough, my GPO software installations deployed successfully. :)

Sean P.
  • 121
  • 1
  • 4