I have recently run into the "Guest access in SMB2 & SMB3" issue outlined by Microsoft here, and I am trying to understand the full scope of the issue. So far as I can tell, this only impacts NAS access or the like, because a share on a domain member computer is not accessed as a guest. However, I have an account on my NAS, with matching name and password, and permissions are handled properly. Meaning, on a Windows build that doesn't have the outlined problem, I CAN access folders that user has permissions for, and I can't access folders that user doesn't have permission for. Which seems like I am NOT accessing the NAS as a guest, but rather with user credentials. So, can someone explain what is actually happening under the hood?
Also, I was alerted to the issue because a customer was seeing this behavior, and the "fix" outlined by Microsoft is not working for them. Their scenario is slightly different in that they are using Azure in a way that I am not familiar with, basically syncing Group Policy, or at least permissions, with Azure. But Microsoft's information linked above makes no mention of Azure at all, so not sure what the Azure based version of Group Policy is capable of.
And finally, on my Windows 10 Enterprise VM, accessing a Synology NAS, I lose not only PowerShell access to the NAS, but Explorer as well. I get the error mentioned in the link.
You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.
But for this customer, the issue is not showing up in Explorer, only (so far as we have seen) in PowerShell. And in PowerShell it manifests as Test-Path failing on a valid path, that we can access in Explorer. Does that suggest some other problem, and my Google-Fu has led me astray?
• The document that you are referring to is basically an official documentation for the support of SMB 2 and SMB 3 in various versions of Windows. Kindly refer to the below table for summary of the whole document: -
• The document implies that starting from adoption of support for SMB 2 and 3, the guest account authentication by default for access to the remote network shares is not possible/is denied and in some cases, will be given access as a guest user (with least possible privileges to the files of that network share) when the actual user credentials entered when asked are not verified. The document also states that SMB 1 is not supported in the versions of Windows stated above in the table. In the above table too, certain versions of Windows 10 require an update is for the stated behavior of guest account earlier while certain versions of Windows 10 where update is not required, the administrator has the authority to allow guest user access to remote network shares.
• Also, guest user logons are disabled by default in various versions of Windows as they do not support standard security features such as signing and encryption thus making them vulnerable to the man-in-middle attacks. Thus, if you want to enable insecure guest logon centrally on all the systems in your network or a subset of systems in your network, then you can do so by enabling the same through a group policy as described below in the link: -
The above setting to enable insecure guest logon is described for on-premises environment while the same setting in group policy can be enabled or set in Azure also through Azure AD Domain Services group policy options. For that purpose, you will need a domain managed by Azure AD Domain Services and a Windows Server VM joined to it acting as the DC of the domain environment. For more details on setting up the Group Policy Management server in Windows Server VM, kindly refer to the link below for more details and then do the same setting as said in the link above. Once you enable the insecure guest logon for your Azure AD managed domain, you will not encounter the same issue again and you would then be able to use powershell with guest access.