Solved SMB problem (again)

M

mefizto

Greetings all,

Upon successful installation of FreeBSD 12.0-RELEASE-p2, I have decided to attack my problems with SMB net/samba4 again.
smb4.conf:
Code: 
# Global configuration
#---------------------------------
[global]
workgroup          = WORKGROUP
netbios name       = SMB
server string      = Laptop
security           = user
max smbd processes = 2
encrypt passwords  = yes
socket options     = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_KEEPALIVE SO
_RCVBUF=65536 SO_SNDBUF=65536
aio read size      = 16384
aio write size     = 16384
strict locking     = Auto
strict sync        = no

# Disable printing
#---------------------------------
load printers           = no
disable spoolss         = yes
show add printer wizard = no

[Home shared folder]
#---------------------------------
  path       = /usr/home/username/share
  public     = no
  writeable   = yes
  browseable  = no
  write list = username
Windows 7 does recognize the machine, both by its netbios name and IP address, but then refuses connect to the share with the (in)famous: "Error code:0x80070035
The network path was not found"

It appears that the problem is not my pf.conf because whether pf is on or off, the error persists. Searching the, mostly Microsoft "advises", is useless.

The problem is the more frustrating, given that my Illumos servers are working flawlessly.

Any advise would be appreciated.

Kindest regards,

M
 
Remove these:
Code: 
socket options     = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_KEEPALIVE SO
_RCVBUF=65536 SO_SNDBUF=65536
aio read size      = 16384
aio write size     = 16384
strict locking     = Auto
strict sync        = no
They'll do more harm than good.

Instead of this:
Code: 
[Home shared folder]
#---------------------------------
  path       = /usr/home/username/share
  public     = no
  writeable   = yes
  browseable  = no
  write list = username
Use this:
Code: 
[homes]
   comment = Home Directories
   browseable = no
   writable = yes
 
Hi SirDice,

thank you for the answer. I have modified the smb4.conf per your advice, but to no avail. I also re-introduced the line
Code: 
path = /usr/home/username/share
because as I understand a share must be defined, but again to no avail.

Is there any other way to analyze the connection attempt?

Kindest regards,

M
 
This is the homedir share configuration from my smb4.conf that has been working for me for quite some time now (win7/10):
Code: 
[homes]
        comment = Home directory
        valid users = %S
        read only = no
        create mask = 0600
        directory mask = 0700
        browseable = no
 
Hi mickey,

thank you for your reply; however, again, the same error. I have been so desperate to have this fixed that I even followed the advices from Microsoft fora, but nothing works.

I guess, I will be unable to make FreeBSD a samba server, back to Illumos.

Kindest regards,
 
mefizto said:
Hi mickey,

thank you for your reply; however, again, the same error. I have been so desperate to have this fixed that I even followed the advices from Microsoft fora, but nothing works.

I guess, I will be unable to make FreeBSD a samba server, back to Illumos.

Kindest regards,
Click to expand...

What Windows version do your clients run and did you change any SMB related settings on the client side? I barely remember that there was couple of settings in the local security settings related to SMB min protocol version, authentication, secure channel, etc that needed some tweaking in older Windows versions (2000/XP/7) to get things to work.
 
Hi mickey,

Yes, I had had changed these settings, when I had been setting the Illumos server. I confirmed by looking through the Microsoft advices, that they are correctly set. Is there a log or some settings that would let me review the connection negotiation?

On a slightly different note, I also cannot mount the Illumos server.

Kindest regards,

M
 
For me, Windows 7 and 10 clients work with Samba 4.8.x on FreeBSD 12.0-RELEASE-p2 with the respective default settings. In smb4.conf(5) I need to specifiy only a few settings:
Code: 
[global]
workgroup = SERVER
server string = Server
security = user
encrypt passwords = yes
log level = 0
max log size = 500
preferred master = yes
hosts allow = 192.168.1.
interfaces = em0
bind interfaces only = yes
socket options = TCP_NODELAY
ntlm auth = yes

[homes]
comment = Private Directories
browseable = no
writeable = yes
directory mask = 0700
create mask = 0600
veto files = Shared Files/

TCP_NODELAY is good to have in place specially for Windows clients.
ntlm auth = yes is not for Windows, but for an old multifunction laser printer, which is configured to store it’s scan files on a SMB share on the server and which does not support the new authentication mechanisms.
 
Hi obsigna,

I do not know how to thank you, your smb4.conf works.

You specify in
Code: 
 [global]
log level = 0
max log size = 500
but it is not clear to me, even with reference to smb.conf(5) where is the log file. Could you amplify?

Kindest regards,

M
 
Greetings all,

this is really getting to me. After I restarted the FreeBSD machine this morning, without making any changes, I again cannot connect, this time with an error message: "Logon failure: unknown user name or bad password." And no, I did not mis-typed or have caps lock on. Also, there is no problem with the network connection since I can ping the FreeBSD machine .

The log file SirDice pointed to just shows:
Code: 
[2019/01/29 11:11:51.688945,  0] ../lib/util/become_daemon.c:138(daemon_ready)
  daemon_ready: STATUS=daemon 'smbd' finished starting up and ready to serve con
nections

No messages indicating failure.

Kindest regards,

M
 
Set log level to all. Then restart and try again. Look again into the logfile for something more enlightening with respect to the login problem.
 
HI obsigna,

thank you again. Being now suspicious of anything related to net/samba4, I checked that the option all is available, but the syntax is all: X, where X is the level.

The log showed that the connection negotiation fails on NTLMv1 password authentication. This is strange because samba.conf(5) recites in section "ntlm auth (G)": "Default: ntlm auth = yes". However, setting this option explicitly in the [global] part of samba.conf(5) rectified the problem.

In that regards, you have noted that:
obsigna said:
ntlm auth = yes is not for Windows, but for an old multifunction laser printer, which is configured to store it’s scan files on a SMB share on the server and which does not support the new authentication mechanisms.
Click to expand...
This does not seem to correlate with my experience. Could you try to remove this option?

In any even, since the current version of net/samba4 and Windows since Vista support NTLM2, I set it at all of my machines. I will mark the thread solved after doing some more testing.

Kindest regards,

M
 
I just checked it, and I can login to the Samba 4.8 shares on my FreeBSD home server from Windows 7 clients also after I removed ntlm auth = yes. In one of your posts, you confessed that you changed SMB settings on the client side for adapting it to Illumos’s Samba. You want to reset SMB on your Windows machines to it’s previous default settings, because this is known to work.
 
Hi obsigna,

thank you for trying. I have been experimenting with the settings, i.e., removal/insertion of the ntlm auth = yes, and the behavior is consistent; without it, the password authentication fails, with it it works. I am thus wondering, if I have some other problem, that might manifest itself later. But the /var/log/samba4/log.smbd is so cryptic, that I do not even know, where to start.

Regarding the settings on the Windows machine for Illumos, I verified that it was "Send LM & NTLM - use NTLMv2 session security when negotiated", wherein the NTLM is understood to refer to NTLMv1, thus I thought it should work for FreeBSD due to the defalut setting of the ntlm auth = yes, now I changed the setting to "Send NTLMv2 response only", which is supposedly safer.

Kindest regards,

M
 
Take a look into the release notes of Samba 4.5:
Code: 
...
NTLMv1 authentication disabled by default
-----------------------------------------

In order to improve security we have changed
the default value for the "ntlm auth" option from
"yes" to "no". This may have impact on very old
clients which doesn't support NTLMv2 yet.
...
 
For what it's worth, I have this in my smb4.conf to support some of my nostalgic VMs running windows 98 and earlier:

Code: 
# support for lanman and win9x machines
lanman auth = Yes
client lanman auth = Yes
client plaintext auth = Yes
ntlm auth = yes

But I am also using LDAP for authentication:

Code: 
passdb backend = ldapsam:"ldap://ldap.example.com"
ldap admin dn = cn=Manager,dc=example,dc=com
ldap connection timeout = 2
ldap debug level = 0
ldap debug threshold = 10
ldap delete dn = no
ldap deref = auto
ldap follow referral = auto
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Computers
ldap page size = 1024
ldap passwd sync = no
ldap replication sleep = 1000
ldapsam:editposix = no
ldapsam:trusted = no
ldap ssl = start tls
ldap suffix = dc=example,dc=com
ldap timeout = 15
ldap user suffix = ou=People
 
Hi obsigna,

I have been looking at wrong samba.conf(5). I have just checked man smb.conf, and you are correct. It still does not explain why, since we both run the same net/samba4(), it works for you and not for me.

Regardless, thank you once again for your patience.

Kindest regards,

M
 
mefizto said:
... It still does not explain why, since we both run the same net/samba4(), it works for you and not for me. ...
Click to expand...

Because you fiddled with the SMB settings of your Windows clients, it does not work for you, and because I left the SMB settings of my Windows clients alone, it works for me. For me, this is perfectly clear.
 
Microsoft has disabled SMBv1 on all supported Windows versions. Don't be tempted to enable it again, it's horribly insecure and there's quite a lot of malware around that abuses it (WannaCry is probably the best known).
 
Hi obsigna,

maybe, but I doubt it because I just checked a fresh installation of Windows 7 with all default settings, and the "Network Security: LAN Manager authentication level" is set to "Not Defined". As such the setting disables any negotiation, as I have just verified. In other words, unless your installation pre-set this value to other than "Not defined", this value must be "fiddled with" as you aptly put it.

Saying that, I am satisfied that the "Send NTLMv2 response only" is the correct one. Thus, thank you once again for all your help.

Hi SirDice,

we are not discussing the version of samba, but rather the version of LAN authorization. Or did you mean to write NTLMv1 instead of SMBv1? Or is there something else I am not understanding.

Anyway, thank you all the participants, your help is greatly appreciated.

Kindest regards,

M
 
mefizto said:
we are not discussing the version of samba,
Click to expand...
No, I'm talking about the SMB protocol, SMB / CIFS / SMB1. Since it's been turned off by default it's often the reason why a modern Windows client can't connect to a Samba server.

NTLM (version 1 or 2) is only part of that puzzle and shouldn't be used any more either, Microsoft still supports it but has been advising everyone to stop using it for almost 10 years now.

NTLM - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Hi SirDice,

thank you for the explanation. However, I saw in the log file that the connection attempt is made using SMBv2; thus, this was not the cause of the problem.

If "NTLM (version 1 or 2) . . . shouldn't be used any more either" as you wrote, what authentication protocol should be used? I do not see any other option in the "Network Security: LAN Manager authentication level".

Kindest regards,

M
 
You must log in or register to reply here.
Back
Top