SMB issues due to settings related to domain - what settings should I be using?

Status
Not open for further replies.

Stilez

Guru
Joined
Apr 8, 2016
Messages
529
I've finally tracked down the obscure SMB issues that have been plaguing my LAN, but I'm not sure what to do to fix it, or what settings I should be using. The issues relate (I am now sure) to how I'm configure domain names and domain related matters on my LAN, and probably someone experienced would instantly see what I should be doing.

  • Platforms and OSes - Simplifying to the 'problem' elements, the LAN has Windows 8.1 clients, a pfSense router, and FreeNAS running Samba. The router and FreeNAS are both latest versions (2.3.4-p1 and 11.0-U2 respectively). FreeNAS has no extensions/VMs/modding and not many services enabled (SSH, SMB, SMART, iSCSI while troubleshooting). It was clean-installed as 9.10.2 and updated to 11.0, and has always been configured through the GUI. The hardware is all stable and reputable (SuperMicro/Chelsio/Intel).
  • General LAN setup - The LAN is a small homebrew/homelab LAN on one site; eventually it'll have a TAP VPN link to a second site so I need to allow for that, and also allow for servers offline/unreachable occasionally in my services planning. There is no purchased domain name, and no AD/LDAP. The only times one LAN device accesses another, it uses either the SMB name (for SMB) or its IP (for everything else). The router runs DHCP and Unbound as a DNS resolver, and all devices use the router for DNS lookup. SMB is used both client-server and client-client. Samba is configured to use WINS rather than broadcast (at present there's only one device able to act as a WINS server, and if FreeNAS is offline the clients would revert to broadcast anyway to find each other). If the FreeNAS server needs its NetBIOS names to be available for lookup, it can be added to the router's unbound.conf as a specific host -> IP entry. Packet capture confirms no firewall-related issues or dropped packets.
  • Domain name entry issue - There's a number of places where one has to specify names for devices, some of them including domain names, others where a workgroup is needed, a domain is optional, or only a NetBIOS name is required. I'm convinced that my choices of what to enter and which of these to enter a domain in, and the format of the domains, isn't compatibly entered across my devices, and that's the source of my issues.

    For example,

    — pfSense and FreeNAS both require a name to be given - but pfSense demands a domain of some kind (even if not needed otherwise) and forbids ".local" (it breaks discovery for Apple and other devices using Ahavi/mDNS for discovery which is relevant here), while FreeNAS demands one and says if it no other name exists, ".local" should be used.
    — pfSense Unbound has a places to add hosts needing lookup, which could contain a NetBIOS name or FQDN.
    — Windows IPv4 config has an optional box to enter a "DNS suffix" which can be filled or left empty and could be used to enter a domain name.
    — Client LAN credentials, used for SMB lookup and entered in Windows Credential Manager, require a remote device name (which could be entered as a plain NetBIOS name or a FQDN), and a "user" or "domain\user" where the "domain" element could be a NetBIOS device name, NetBIOS workgroup name, FQDN or omitted.
    — Samba and Windows machine name both need a name, but it's unambiguously just the NetBIOS name, not the FQDN here.
    — Windows explorer.exe and "NET USE" commands both need a name, which can be a NetBIOS name or FQDN. (But only NetBIOS names will be discovered automatically by Explorer.exe)
    — WINS can also (I think) have entries hard-coded through its config in some format or other, but I'd like to avoid this, and avoid using HOSTS files.
Because the behaviour changed and the problem shifted when I played with the domain-related fields, and the logs showed issues that related to empty domain and/or user fields, I'm sure that my SMB issues are because that I don't really know which of these fields to enter what in - meaning, which of these need a domain or workgroup, or for which it's optional, which of the above would get a domain from another device or which require it manually entered or to match the entry elsewhere, and so on.

Symptoms that make me believe this is my issue, are that log.smbd was showing various messages of the form "[ ] / [ ] @ CLIENT_MACHINE_NAME", and later on, "check_ntlm_password: Authentication for user [ ] -> [ ] failed with error NT_STATUS_NO_SUCH_USER" and "sam authentication for user [ ] failed", which seemed to be due to the correct data not being supplied by the client devices (Wireshark showed the original SMB request/negotiation packets had empty domain/username fields when sent). But when I added an arbitrary domain in the Windows credential it suddenly started to be able to authenticate to Samba file shares and list them in "NET USE" (although still not discover them in the navigation pane).

But this then seemed to break other things; I couldn't figure what exactly I need to enter in which of these fields to make it all work together. I've tried doing magic random guesses - maybe workgroup here and domain there; maybe domain here and omit it there... but that's not really a great way to troubleshoot.

So my question is, what data do I enter in each of the various fields above so that SMB shares will stand a chance of working properly, including Network Places discovery/lookup? A list of "setting -> value" appropriate for my setup would honestly be good enough.

Some example data to make it easier:

— pfSense host name: set to "router.SOME_DOMAIN_NAME";
— FreeNAS host name, Samba workgroup, and NetBIOS name: set to "filesvr.SOME_DOMAIN_NAME", "WORKGROUP", and "filesvr" respectively;
SOME_DOMAIN_NAME is arbitrarily set to ".mydomain" (on the assumption .local might cause problems);
— An example user defined in smb.conf, and created in FreeNAS users/groups: "Mike";
— An example client PC's workgroup and NetBIOS name: "WORKGROUP" and "WINPC2" respectively;
— Null-password, unknown password->guest mapping, guest, and unauthenticated logins+enumeration are all disabled in Samba. So are homegroups on PCs. So are $IPC shares (if possible without killing Network Places discovery). The user names and passwords on the PCs are different from those in Samba.
 
Last edited:

Stilez

Guru
Joined
Apr 8, 2016
Messages
529

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
I
I've finally tracked down the obscure SMB issues that have been plaguing my LAN, but I'm not sure what to do to fix it, or what settings I should be using. The issues relate (I am now sure) to how I'm configure domain names and domain related matters on my LAN, and probably someone experienced would instantly see what I should be doing.

  • Platforms and OSes - Simplifying to the 'problem' elements, the LAN has Windows 8.1 clients, a pfSense router, and FreeNAS running Samba. The router and FreeNAS are both latest versions (2.3.4-p1 and 11.0-U2 respectively). FreeNAS has no extensions/VMs/modding and not many services enabled (SSH, SMB, SMART, iSCSI while troubleshooting). It was clean-installed as 9.10.2 and updated to 11.0, and has always been configured through the GUI. The hardware is all stable and reputable (SuperMicro/Chelsio/Intel).
So far so good. :D
  • General LAN setup - The LAN is a small homebrew/homelab LAN on one site; eventually it'll have a TAP VPN link to a second site so I need to allow for that, and also allow for servers offline/unreachable occasionally in my services planning. There is no purchased domain name, and no AD/LDAP. The only times one LAN device accesses another, it uses either the SMB name (for SMB) or its IP (for everything else). The router runs DHCP and Unbound as a DNS resolver, and all devices use the router for DNS lookup. SMB is used both client-server and client-client. Samba is configured to use WINS rather than broadcast (at present there's only one device able to act as a WINS server, and if FreeNAS is offline the clients would revert to broadcast anyway to find each other). If the FreeNAS server needs its NetBIOS names to be available for lookup, it can be added to the router's unbound.conf as a specific host -> IP entry. Packet capture confirms no firewall-related issues or dropped packets.
Have you configured dhcp in pfsense so that it's telling the dhcp clients that the FreeNAS server is providing WINS?
  • Domain name entry issue - There's a number of places where one has to specify names for devices, some of them including domain names, others where a workgroup is needed, a domain is optional, or only a NetBIOS name is required. I'm convinced that my choices of what to enter and which of these to enter a domain in, and the format of the domains, isn't compatibly entered across my devices, and that's the source of my issues.

    For example,

    — pfSense and FreeNAS both require a name to be given - but pfSense demands a domain of some kind (even if not needed otherwise) and forbids ".local" (it breaks discovery for Apple and other devices using Ahavi/mDNS for discovery which is relevant here), while FreeNAS demands one and says if it no other name exists, ".local" should be used.
Don't use ".local". That's a hold-over from a bygone era.

Symptoms that make me believe this is my issue, are that log.smbd was showing various messages of the form "[ ] / [ ] @ CLIENT_MACHINE_NAME", and later on, "check_ntlm_password: Authentication for user [ ] -> [ ] failed with error NT_STATUS_NO_SUCH_USER" and "sam authentication for user [ ] failed", which seemed to be due to the correct data not being supplied by the client devices (Wireshark showed the original SMB request/negotiation packets had empty domain/username fields when sent). But when I added an arbitrary domain in the Windows credential it suddenly started to be able to authenticate to Samba file shares and list them in "NET USE" (although still not discover them in the navigation pane).
Typically, you would either authenticate with the older style "domain\username" (i.e. FREENAS\Bob) or new-style UPN username@fqdn. (i.e bob@freenas.foo.com).

But this then seemed to break other things; I couldn't figure what exactly I need to enter in which of these fields to make it all work together. I've tried doing magic random guesses - maybe workgroup here and domain there; maybe domain here and omit it there... but that's not really a great way to troubleshoot.

So my question is, what data do I enter in each of the various fields above so that SMB shares will stand a chance of working properly, including Network Places discovery/lookup? A list of "setting -> value" appropriate for my setup would honestly be good enough.


Some example data to make it easier:

— pfSense host name: set to "router.SOME_DOMAIN_NAME";
— FreeNAS host name, Samba workgroup, and NetBIOS name: set to "filesvr.SOME_DOMAIN_NAME", "WORKGROUP", and "filesvr" respectively;
SOME_DOMAIN_NAME is arbitrarily set to ".mydomain" (on the assumption .local might cause problems);
— An example user defined in smb.conf, and created in FreeNAS users/groups: "Mike";
— An example client PC's workgroup and NetBIOS name: "WORKGROUP" and "WINPC2" respectively;
— Null-password, unknown password->guest mapping, guest, and unauthenticated logins+enumeration are all disabled in Samba. So are homegroups on PCs. So are $IPC shares (if possible without killing Network Places discovery). The user names and passwords on the PCs are different from those in Samba.

If your DNS resolver is overriding "foo.com", then your settings would be something like the following:
  • pfsense hostname = router.foo.com
  • freenas hostname = filesvr.foo.com
  • freenas workgroup = foo
  • freenas netbios name = filesvr
  • client pc hostname = winpc2.foo.com
  • client pc workgroup = foo
  • client pc netbios name = winpc2

Overriding an existing domain for your local DNS is fine (as long as you don't need to go to the site(s) you're overriding), and can provide fun on April fool's day.

P.S. killing "IPC$ shares" basically kills network places discovery. How are you doing this?
 

Stilez

Guru
Joined
Apr 8, 2016
Messages
529
@anodos, @dlavigne - thanks and here are answers + further info:
  • pfSense is passing <FreeNAS IP> as part of DHCP.
  • I changed the config so all devices are "*.lab.mynet" (router.lab.mynet, svr.lab.mynet, <PC_NAME>.lab.mynet etc). pfSense passes it with DHCP (as always), and there are no special settings on the client Network Adapter config. "ipconfig/all" says that the clients are picking it up correctly from pfSense:
OUTPUT OF "IPCONFIG/ALL":
Host Name . . . . . . . . . . . . : TEST_PC
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : lab.mynet

Ethernet adapter Ethernet Intel:

Connection-specific DNS Suffix . : lab.mynet
Description . . . . . . . . . . . : Intel(R) 82579V Gigabit Network Connection
Physical Address. . . . . . . . . : <INTEL MAC ADDRESS>
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.100.0.5(Preferred)
Subnet Mask . . . . . . . . . . . : 255.0.0.0
Lease Obtained. . . . . . . . . . : 02 August 2017 19:22:31
Lease Expires . . . . . . . . . . : 02 August 2017 22:22:31
Default Gateway . . . . . . . . . : <pfSense IP- correct, works>
DHCP Server . . . . . . . . . . . : <pfSense IP- correct, works>
DNS Servers . . . . . . . . . . . : <pfSense IP- correct, works>
Primary WINS Server . . . . . . . : <FreeNAS IP- correct>
NetBIOS over Tcpip. . . . . . . . : Enabled
  • Also Wireshark shows pfSense resolving unknown LAN device names on the LAN. After flushdns/nbtstat -R, when I type "ping some_vm" I see DNS queries to pfSense and replies coming back from it. If 'some_vm' doesn't exist pfSense is correctly returning "No such name" and ping replies host unreachable, which shows clients aren't doing unexpected fallback or getting confused on resolution.
Beyond that, everything's a snafu, especially Samba browsing + auth where I'm a complete mess.
The actual symptoms have changed a bit since I first posted. I've tracked what I did but can't reproduce whatever changed it. So I've included debug info and also summarised what I'm trying to do. It might be easier to troubleshoot, or to start afresh, I don't know.
  • When I posted this thread, the symptom appeared to be well defined and stable: user+domain (as passed by the client when browsing or trying to authenticate) were null "user+domain" fields in Wireshark and in Samba logs during auth. I spent ages trying everything, flush and retest, stop and start Samba, but couldn't shift that symptom.
  • Finally after a few days I happened to switch off "Master Browser" on the server and suddenly shares seemed to start working fine. No idea why, as it was still the "preferred browser" anyway.
  • The next morning it had changed again. They would now only connect if I entered the full FQDN in my share logon \\(svr.lab.mynet\USERNAME). 2 days later and nothing I enter will auth at all, the smbd log consistently reports auth issues (see below). I have no idea why, or why they started to work, or why they now stop with a different symptom.
  • So the issue as it stands *now* has become, I can't find any valid logon Samba will accept. But at least the fields aren't empty. They're just "strange" (see below). When Windows asks for a user+pw I've tried MY_PC\name, SVR\name, WORKGROUP\name, and plain "name", and tried the same in Credential Manager, but none are being accepted. net use \\svr and net use \\svr\\SHARE_NAME both give "access denied". But I can logon using the same username+pw in other ways, so the user/PW combo should be valid. Perhaps group/ownership/ACLs are screwy, or perhaps the clients are still passing wrong (or differently wrong) auth data?
Here's the SMBD log messages and my smb4.conf. The log shows SMB requests where the user+domain again look weird to me, although not blank like before:
SMBD LOG FOR CURRENT FAILED AUTH'S:

Got user=[USERNAME] domain=[PC1_NAME] workstation=[PC2_NAME] len1=24 len2=294
Checking password for unmapped user [PC1_NAME]\[USERNAME]@[PC2] with the new password interface
mapped user is: [SVR]\[USERNAME]@[PC2_NAME]
Forcing Primary Group to 'Domain Users' for USERNAME
NTLMv2 password check failed
Lanman passwords NOT PERMITTED for user USERNAME
LM password and LMv2 failed for user USERNAME, and NT MD4 password in LM field not permitted
Authentication for user [USERNAME] -> [USERNAME] FAILED with error NT_STATUS_WRONG_PASSWORD
The user+pw dialog was given the right password for USERNAME, which was the correct username. I've tried different data and get similar errors. I don't understand how it's managed to get the names of *two different* clients in one request(!) but it did, or what it means by "forcing primary group to domain", or why it's doing it, as I'm not using AD/LDAP. Rejecting LANMAN is correct though: the test client is Win 10 and LANMAN + NTLMv1 are disabled at both ends, in Secpol.msc ("Send NTLMv2 response only, refuse LM+NTLM" - just rechecked) and in smb4.conf, and minimum protocol is set server-side to SMB3.02.

smb4.conf:

server min protocol = SMB3_02
server max protocol = SMB3
encrypt passwords = yes
dns proxy = no
strict locking = no
oplocks = yes
deadtime = 15
max log size = 51200
max open files = 2826902
logging = file
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
getwd cache = yes
guest account = nobody
map to guest = Bad User
obey pam restrictions = no
ntlm auth = no
directory name cache size = 0
kernel change notify = no
panic action = /usr/local/libexec/samba/samba-backtrace
nsupdate command = /usr/local/bin/samba-nsupdate -g
ea support = yes
store dos attributes = yes
lm announce = yes
hostname lookups = yes
time server = yes
acl allow execute always = true
dos filemode = yes
multicast dns register = yes
domain logons = no
local master = no
idmap config *: backend = tdb
idmap config *: range = 90000001-100000000
server role = standalone
netbios name = SVR
workgroup = WORKGROUP
security = user
pid directory = /var/run/samba
create mask = 0666
directory mask = 0777
client ntlmv2 auth = yes
dos charset = CP850
unix charset = UTF-8
log level = 3
# set socket options
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE
# cache current directory content
getwd cache = yes
# speed up SMB by not testing if same filename exists with different casing, when saving
case sensitive = yes
preserve case = yes
short preserve case = yes
# Preferred master - NetBIOS master browser controls
preferred master = yes
os level = 200
# Time between checks for an inoperative client (secs)
keepalive = 45
# ABOVE HERE ALL WORKS FINE
# dns proxy = yes
# Yes it's inconsistent with previous "dns proxy = no". From MAN page seems correct? To check.
name resolve order = wins host bcast
wins support = yes
auth methods = sam
map to guest = Never
null passwords = no
encrypt passwords = yes
# encrypt pw also ensures clients unable to offer SMB3+ can't connect
hosts allow = 10.0.0.0/8 192.168.0.0/16 127.0.0.0/8
# SMB client settings (for use as a client or debugging the client side)
client NTLMv2 auth = yes
client min protocol = SMB3_00
client lanman auth = no
client plaintext auth = no
client signing = mandatory
client use spnego = yes


[SHARE_NAME]
path = "/mnt/POOL_NAME/SHARE_NAME"
printable = no
veto files = /.snapshot/.windows/.mac/.zfs/
writeable = yes
browseable = yes
recycle:repository = .recycle/%U
recycle:keeptree = yes
recycle:versions = yes
recycle:touch = yes
recycle:directory_mode = 0777
recycle:subdir_mode = 0700
vfs objects = zfs_space zfsacl streams_xattr recycle aio_pthread
hide dot files = no
guest ok = no
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = true
zfsacl:acesort = dontcare
Another persistent symptom is that the output of "nbtstat" from the client isn't as I'd expect throughout all of this. For example, "ipconfig/flushdns" + "nbtstat -RR" +"nbtstat -c" I get <00> and/or <20> for various client machines, but the server isn't listed, and "nbtstat -a SVR_IP" gets me a list that contains the server and workgroup but no clients. But WINS is working and wins.dat + tdbdump wins.tdb both show what I'd expect, all devices and rewasonable entries for <00><1e><20>, and file updated recently hence not stale data. It also doesn't seem to be a firewall issue and network places browsing + file sharing works between clients just not client-to-server. No idea what to make of it.

I've tried various Samba diagnostics and issue tracing - testparams is fine, ACLs were initially set and shouldn't have changed (but I've lost where to check the share owners in the GUI and can't remember now whether the top level shares should be owned by root/wheel or whatever group I entered initially or some ACL).

Thinking about it, it's worth checking if UNIX permissions/ACLs on the shared dirs. got scrambled. I am not sure how to do that, as I've never had to work with permissions/ACLs setup on a top level shared dir from the server side, and not sure what they should look like - root, wheel, some user group, whatever. The shares are all Windows ACLs and have worked before; I've previously set ACLs on their root from a client PC, I have a vague memory of seeing wheel where I expected to see a specific user group one time.

Approaching it from the other end, what I'm actually trying to do is:
  1. I'm trying to minimise broadcast resolution and apart from where it's still needed, use broadcast only when FreeNAS is offline for clients to still find clients. Ie., use port 445 primarily and use just DNS+WINS if a WINS server exists, but if the WINS server is down, clients should fall back on broadcast or a fallback WINS server, so that client-to-client network share browsing still works, as it's used a lot.
  2. I want network places to work, so that shares can be seen by any other machine that passes authentication+authorisation requirements upon connection
  3. I'd like login mechanisms to be limited to SMB3+ and NTLMv2 only, and to block any browsing of the LAN or enumerating of shares by a client that can't offer a valid auth (also reject null passwords, and disable failover to "guest" if auth fails or user unknown). According to Microsoft's docs, requiring encryption+signing acts as a workaround to do this; it forces clients who can't offer SMB3+ to fail automatically even before any enumeration or auth handshake, because SMB2.x clients simply can't do encrypted connections.
  4. There's no directory services hence no PDC, domain servers, or LDAP for external auth. LDAP/AD seems overkill (I'd use it for file share tracking but nothing else). So the only auth method available at the moment for Samba is the local database of users+groups ("sam").
  5. The LAN is on two sites with TAP connection so broadcasts pass between, but right now the sites are 100% disconnected and the VPN link disabled while I'm trying to get one site working reliably with Samba. I'll tackle connecting them later. There's only one workgroup, all computers and Samba are set to be members of "WORKGROUP".
 
Last edited:
Status
Not open for further replies.
Top