SOLVED SMB Problem on WIN 10 Client (FN11-RC)

[maydo]

Hi,

i have one win 10 client which cannot connect to smb shares from freenas. (authentication fails. password or wrong login)

all other win 10, win server, linux clients (on same network) are working fine, its just one client with this problem.

i have migrated zpool from corral to > fn11 > created smb shares etc.

smb min 2 max 3 (also tried until to ----- min protocol)

it must be something on the client.

the funny thing about,
this client was connecting fine to corral, also connects to all other smb shares, from qnaps, ubuntus etc.

i have googled 1000 sites, since 6 days, tried so many things, resetting network, reinstall nic switching to wifi or lan etc etc.

i have no more idea

any ideas ?

 

[Ericloewe]

What's the exact version of Windows? Maybe it's not on the latest or maybe it got the latest earlier...

 

[maydo]

version is 10.0.14393.0

this version is also running on the other working clients.

 

[Jailer]

Sounds like incorrect credentials are cached on the client.

 

[maydo]

Sounds like incorrect credentials are cached on the client.

i have deleted them more than one time

 

[Ericloewe]

Different antimalware suite on that specific client?

I'm kinda grasping at straws here...

Maybe that client is trying something weird the domain part of the username?

 

[maydo]

is onboard windows defender on all clients.

just tried switching off, but same.

also the credentials are ok.

there are clients in network which are windows domain members and some not, i can connect with all clients.

the affected client is not a member, i have tried also including to the windows domain. same result.

i have tried also some serverside debugging, switched log level on freenas to "debug" and have checked the log files, but dont find any related informations.

i dont know much about windows client smb debugging.

maybee there are some orphaned cached informations on this client.
couse the corral was same local ip on network, just changed hostname on fn11.

 

[anodos]

You can start by using tcpdump on the FreeNAS server to verify that your windows 10 client is actually trying to connect to the FreeNAS server. tcpdump host <ip of windows client> from CLI of FreeNAS. Once you've done that, try increasing logging levels for SMB in samba, then attempt to authenticate from the Windows client. After the failed attempt, post the contents of /var/log/samba4/log.smbd here.

 

[maydo]

Code:

[2017/05/08 14:19:25.150351,  2] ../libcli/auth/ntlm_check.c:423(ntlm_password_check)
  ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user admin
[2017/05/08 14:19:25.150508,  2] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [admin] -> [admin] FAILED with error NT_STATUS_WRONG_PASSWORD
[2017/05/08 14:19:25.151838,  2] ../auth/gensec/spnego.c:768(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_WRONG_PASSWORD

ive found this, password is correct,

i have just checked "NTLMv1 auth:" box and its working :)

but why just this client want use this ? and all other win 10 clients are working without ? there are about 15 win 10 clients in network

 

[anodos]

Code:

[2017/05/08 14:19:25.150351,  2] ../libcli/auth/ntlm_check.c:423(ntlm_password_check)
  ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user admin
[2017/05/08 14:19:25.150508,  2] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [admin] -> [admin] FAILED with error NT_STATUS_WRONG_PASSWORD
[2017/05/08 14:19:25.151838,  2] ../auth/gensec/spnego.c:768(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_WRONG_PASSWORD

ive found this, password is correct,

That message actually means that your client is attempting NTLMv1 auth, which was disabled by default in Samba version 4.5. You should:
1) check LmCompatibilityLevel setting in Windows 10. In Windows > Vista it defaults to 3 (I believe), but I have a suspicion that some software out there is dropping the level to force NTLMv1 auth. If it is set to 0-2, then Windows Clients will not use NTLMv2.
2) If client is Windows 10 Pro, then also alter your local group police. Use "secpol.msc" to alter "Network Security: LAN Manager authentication level" which is located in Security Settings, Local Policies, Security Options. Set it to NTLMv2 response only/refuse LM and NTLM.

 

[maydo]

thx, that was the solution :)

working now without NTLMv1 auth

 

[Ericloewe]

Any ideas as to what misbehaving crapplication might be trying to have Windows use NTLMv1, @anodos?

 

[anodos]

Any ideas as to what misbehaving crapplication might be trying to have Windows use NTLMv1, @anodos?

It's hard to say. Someone would have to track Windows registry changes during the install process for applications. It seems like FreeNAS users are hit pretty hard by it, so I'd say it's (1) probably opensource (2) commonly used among "power users" (3) possibly media-related (4) interacts with SMB shares.

I don't think it's overt malicious activity because this sort of auth downgrade won't typically affect AD networks (clients use kerberos for auth). Then again, I believe there are ways to make clients use NTLM instead of kerberos even in an Active Directory domain. It'd potentially be a link in the chain to compromise a network (makes it easier to harvest credentials), but it seems to still be a rather round-about way of doing it. Much more likely to be cutting and pasting a workaround from the time when windows was transitioning from NTLMv1 to NTLMv2.

Another option of course, is applications that use MSCHAPv2, or need it for 802.1X (think VPNs, freeradius, security software, etc).

In general, bad advice thoroughly permeates the internet. Exhibit A: https://wiki.ubuntu.com/MountWindowsSharesPermanently Note that the official ubuntu wiki on mounting Samba shares in the fstab contains the option "sec=ntlm". *golf clap* Great job ubuntu.

 

[tazinblack]

interesting additional information:

if I change the default registry value of LmCompatibilityLevel in HKLM\SYSTEM\CurrentControlSet\Control\Lsa from the default 2 to 5 which forces the use of NTLMv2 it works as expected, but you have to do this on every client which wants to connect.