Allow public access to Samba share without allowing insecure guest access in Windows

Question

A few years ago, due to security concerns, Microsoft disabled by default the ability to connect as a guest to SMB shares.

In my organization, I have a few shares which I want to be available for access from any computer that connects to the network. We do not have a domain. Everyone brings their own device and connects to the network, then can access services by IP and so on. We have this network share of public stuff, mostly installation kits, which I want every computer to be able to connect to, without editing the configuration of the client to allow insecure guest logins.

Basically, what I think I want but don't know how to do is to have Samba map any user that connects to a specific user on the server (I think it can be done with a user map file), and then additionally, which I haven't found out how to do, have it accept any password as valid (we have PCs with the same user account names and different passwords).

Can this be done? Or is it totally unsupported, no one ever thought of this? It can be a hacky solution, it just needs to work.

In the end, what I want to achieve is to take any PC, connect to the network share, whatever username+password combo gets to Samba, it gets accepted and some user that I choose is used on the client side to do operations on the server, browse etc. This basically equates to emulating what guest access previously allowed doing, without having to go though the hassle of changing that group policy setting on every PC that wants to connect and without exposing them to risk when they roam to another location/network.

Thanks

Answer 1

Basically, what I think I want but don't know how to do is to have Samba map any user that connects to a specific user on the server (I think it can be done with a user map file), and then additionally, which I haven't found out how to do, have it accept any password as valid (we have PCs with the same user account names and different passwords).

Both can be done using the same map to guest = bad user option in Samba, but unfortunately, "emulating" Guest access in this way is exactly what "Guest" access is in SMB.

One problem is that SMB servers do not receive passwords at all; they use NTLM when outside an AD domain and Kerberos within a domain. NTLM is a challenge/response protocol that additionally produces a session key to both peers, which SMB then uses to authenticate each packet (as well as the entire handshake in SMBv3 – this provides a form of MITM protection when negotiating the encryption key for SMBv3).

However, for challenge/response protocols like NTLM or CHAP to work properly, the server must already know the user's password (shared secret) – without it, the server cannot derive the NTLM session key from just the client's response alone (being able to do so would defeat the point of the protocol), and therefore cannot correctly 'sign' the SMB messages.

So the way "Guest" access in SMB works is that the server must indicate to the client, "Your credentials didn't work but I accepted you as guest anyway", so that the client would know to not require SMB message signing. If the server accepted arbitrary NTLM responses but didn't send the "Guest access" indication (if I'm reading the protocol docs right), this would result in the client failing to connect anyway.

In short, you cannot really emulate guest access without implementing actual guest access. Selecting map to guest = bad user means Samba has to indicate that this is a guest session.

(Although according to docs, only the Enterprise or Education editions of Windows 10 disables this by default, while Home/Pro does not – and if you do not have an AD domain, I think it's unlikely that you'll be using Enterprise...)

---

What you could do instead is the opposite: Windows does not require the logged-in user to be used for SMB – on failure it will prompt you for credentials (and will even let you save them), so you could use normal SMB authentication but create a single account with a password that everyone knows (write it next to your office Wi-Fi password). You can have a batch script to pre-save the password using cmdkey.

(This also works when accessing a domain-joined file server via Kerberos.)