Windows 11/SMB Problems

[Vertigo 7]

Windows doesn't really play well with password-less shares. Always a good idea to at least create a local account on the machine you're sharing from and give that security permissions on the share, using that account's username and password to access the share from other devices. Setting the share permissions for 'everyone' is fine. Anywho, you got one of the windows 11 machines in so there's some progress.

So on the work laptop of yours, are you using a VPN? being domain joined shouldn't impact your ability to access a share on your home network. Sounding more like a network issue from this end.

 

[qwerty3656]

I created a new local user on the other windows 11 computer and shared a folder with the new user. Still when I try to access that computer from the "domain computer" I get "you do not have permission to access \\DESKTOP-xxx". It does not even give me a login prompt

 

[Vertigo 7]

Well whatever is going on there, it's definitely not a truenas problem and is abnormal for windows. I'd contact your company's IT department and have their desktop techs give your laptop a once over. They'd be better positioned to diagnose this problem than anyone can from the forums.

 

[qwerty3656]

Just to let you know, I came across a webpage with this solution by running secpol.msc:

"I had to set LAN-Manager-Authenticationlevel to just send NTLMv2.

You will find this setting under Security settings -> local -> Security options -> Network Security: LAN-Manager-Authenticationlevel."

I'm not sure what this even does, but now I can connect to my SMB share.

 

[Vertigo 7]

ahh yeah, that makes sense. NTLM is an authentication mechanism that's been in Windows for a while. Version 1 has some vulnerabilities and should be discouraged from using, but version 2 is fine. I'd bet a GPO or something from your company disabled it. If that's the case, there's a chance it'll end up being disabled again the next time you connect to your work place VPN.

 

[Nightbored]

I would like to confirm that setting the local group policy to NTLMv2 reply only resolved my SMB connection issue as well in Windows 11.

I have been using windows 11 since it opened for the dev channel, and this was always an issue for my laptop.

I run my own windows domain, all my Linux and windows 10 systems were fine.

Glad I saw this thread, now I do not have to debate staying on Win 10 post release!

 

[anodos]

I would like to confirm that setting the local group policy to NTLMv2 reply only resolved my SMB connection issue as well in Windows 11.

I have been using windows 11 since it opened for the dev channel, and this was always an issue for my laptop.

I run my own windows domain, all my Linux and windows 10 systems were fine.

Glad I saw this thread, now I do not have to debate staying on Win 10 post release!

What was GPO set to before you changed it?

 

[Vertigo 7]

@anodos I haven't made any changes to any of my Windows 11 systems and I'm able to access shares on Truenas without issue. The security policy default on all of my machines are "not defined" for NTLM authentication level - default behavior to send NTLMv2 response only for windows vista and above systems, and send v1 responses for XP - NT4 systems.

That being said, I must retract my previous statement. NTLMv2 is indeed vulnerable to attack and is also one of the execution points that was use in the recent print nightmare cve. In short, improper configuration of NTLM could allow an attacker to authenticate to any network share without providing credentials.

The recommended solution is to use other authentication, such as Kerberos, to access network shares. That being said, Truenas does not provide any choice of authentication mechanism that I can see other than enabling NTLMv1. Can't rightly tell what authentication mechanism TrueNAS uses.

 

[anodos]

@anodos I haven't made any changes to any of my Windows 11 systems and I'm able to access shares on Truenas without issue. The security policy default on all of my machines are "not defined" for NTLM authentication level - default behavior to send NTLMv2 response only for windows vista and above systems, and send v1 responses for XP - NT4 systems.

That being said, I must retract my previous statement. NTLMv2 is indeed vulnerable to attack and is also one of the execution points that was use in the recent print nightmare cve. In short, improper configuration of NTLM could allow an attacker to authenticate to any network share without providing credentials.

The recommended solution is to use other authentication, such as Kerberos, to access network shares. That being said, Truenas does not provide any choice of authentication mechanism that I can see other than enabling NTLMv1. Can't rightly tell what authentication mechanism TrueNAS uses.

If you are joined to AD, then NTLMv2 and Kerberos are options. Standalone servers are NTLMv2 only.

 

[Vertigo 7]

If you are joined to AD, then NTLMv2 and Kerberos are options. Standalone servers are NTLMv2 only.

I am AD joined, but I don't see where in SMB to set Kerberos as the authentication option.

 

[anodos]

I am AD joined, but I don't see where in SMB to set Kerberos as the authentication option.

You don't set it as an authentication option. It is default for SMB clients assuming DNS is configured correctly, Client is joined to AD, and server is not accessed via IP address.

 

[Vertigo 7]

You don't set it as an authentication option. It is default for SMB clients assuming DNS is configured correctly, Client is joined to AD, and server is not accessed via IP address.

Ahh then I should be set. I am indeed using Winderz DNS servers, FQDN UNC path, and a domain account to access shares.

I am interested to see if there's any kind of packet capture or something I can run to verify that I am using Kerberos to authenticate, just for peace of mind.

 

[anodos]

Ahh then I should be set. I am indeed using Winderz DNS servers, FQDN UNC path, and a domain account to access shares.

I am interested to see if there's any kind of packet capture or something I can run to verify that I am using Kerberos to authenticate, just for peace of mind.

If you feel like breaking legacy compatibility across your AD domain on a Friday, you can set a GPO in AD to disable NTLM in the domain. This may break many things (well, anything that isn't joined to AD and trying to access SMB shares on domain-joined servers).

 

[Vertigo 7]

I may give that a shot. I have a camera system that uses FTP that I'm using IIS for to save recordings, only thing I can think of that'd be impacted. But i'd still like to see the token exchange or something to know 100% for sure it's taking place.

 

[anodos]

Otherwise, you can get NTLMv2 auth attempts by running following command:

Code:

midclt call smb.status AUTH_LOG '[["Authentication.passwordType", "=", "NTLMv2"]]' | jq
{
  "timestamp": "2021-09-15T09:38:56.192921-0700",
  "type": "Authentication",
  "Authentication": {
    "version": {
      "major": 1,
      "minor": 2
    },
    "eventId": 4624,
    "logonId": "0",
    "logonType": 3,
    "status": "NT_STATUS_OK",
    "localAddress": "ipv4:192.168.0.20:445",
    "remoteAddress": "ipv4:192.168.0.27:40038",
    "serviceDescription": "SMB",
    "authDescription": null,
    "clientDomain": "WORKGROUP",
    "clientAccount": "smbshadowuser",
    "workstation": "FBSD-API-TESTER",
    "becameAccount": "smbshadowuser",
    "becameDomain": "TRUENAS",
    "becameSid": "S-1-5-21-261536503-3865662536-3224376528-1009",
    "mappedAccount": "smbshadowuser",
    "mappedDomain": "WORKGROUP",
    "netlogonComputer": null,
    "netlogonTrustAccount": null,
    "netlogonNegotiateFlags": "0x00000000",
    "netlogonSecureChannelType": 0,
    "netlogonTrustAccountSid": null,
    "passwordType": "NTLMv2",
    "duration": 36511
  }
}

 

[Nightbored]

What was GPO set to before you changed it?

As the policy had not been configured it was set to "not defined" as Vertigo 7 mentioned.

Now, I am curious if I am missing something, but is there a way to add truenas to my domain to allow for Kerberos authentication?

I am running dual Windows Server 2019 DCs with DNS.

@Vertigo 7 were your windows 11 systems joined to a domain as well?
If so, I wonder why some systems like my laptop had issues, but not yours.

 

[Vertigo 7]

Interesting. Thanks for that command, both my client systems are indeed logged with NTLMv2, however, I'm not able to see any logs for any of my DCs or other Windows servers when i access shares on the TrueNAS server. Is it expected that kerberos autentications aren't logged?

Code:

midclt call smb.status AUTH_LOG  | jq

Nothing but NTLMv2

 

[anodos]

Interesting. Thanks for that command, both my client systems are indeed logged with NTLMv2, however, I'm not able to see any logs for any of my DCs or other Windows servers when i access shares on the TrueNAS server. Is it expected that kerberos autentications aren't logged?

Code:

midclt call smb.status AUTH_LOG  | jq

Nothing but NTLMv2

Kerberos auth won't necessarily log here. This suggestion was to see what clients are using NTLMv2.

 

[Vertigo 7]

As the policy had not been configured it was set to "not defined" as Vertigo 7 mentioned.

Now, I am curious if I am missing something, but is there a way to add truenas to my domain to allow for Kerberos authentication?

I am running dual Windows Server 2019 DCs with DNS.

@Vertigo 7 were your windows 11 systems joined to a domain as well?
If so, I wonder why some systems like my laptop had issues, but not yours.

Set it up through Directory Services and Active Directory. In theory all you need to provide is the domain name and domain admin creds to join and you're set if you've already pointed NTP and DNS at your DCs.

No, my desktop and laptop are not currently domain joined. I'm logged in with MS accounts on both and using domain accounts to access network shares/resources. Though I'm tempted to now spin up a Windows 11 VM and domain join it and test share access. But Since my TrueNAS server is also domain joined, I'd expect, based on behavior of all of my Windows Server systems, that it'd use kerberos to authenticate and not present the NTLM issue.

It could be that MS implemented a patch as well that disabled NTLM on domain joined systems due to the recent CVE with print nightmare and such. I'd need to look more into their deployed solutions to know more. Could also be a bug, W11 is beta, after all.

Kerberos auth won't necessarily log here. This suggestion was to see what clients are using NTLMv2.

Ahh, ok. Thx, at least I know what muh stuff is doing.

 

[Nightbored]

Set it up through Directory Services and Active Directory. In theory all you need to provide is the domain name and domain admin creds to join and you're set if you've already pointed NTP and DNS at your DCs.

I have no idea how I missed that option... I may hold off though as I am thinking of switching that server to proxmox, and virtualizing truenas as I use a lot of vlans, and cannot seem to get around the global default gateway issue with TrueNAS.

Rant for another day I suppose, but I use proxmox for all my virtualization, and like that on the VM I can specify a gateway and vlan.

No, my desktop and laptop are not currently domain joined. I'm logged in with MS accounts on both and using domain accounts to access network shares/resources. Though I'm tempted to now spin up a Windows 11 VM and domain join it and test share access. But Since my TrueNAS server is also domain joined, I'd expect, based on behavior of all of my Windows Server systems, that it'd use kerberos to authenticate and not present the NTLM issue.

I should probably spin up a truenas server, and VM of Win 11 to test it both ways... Maybe that should be a weekend project...