This article is part of a series of tutorial posts I wrote on configuring a cloud data center on Aruba Cloud using the Cloud PRO service model: a typical IaaS public cloud environment, not too different from Amazon AWS, Google Cloud Platform and MS Azure approach in terms of overall logic.
In this post we'll talk about one of the common issues that we could likely face when we try to activate the file system sharing through the internal LAN, so that servers (and/or VPN users) could access the shared folders using the Windows File Explorer.
Here's a list of steps that we need to do in order to make it happen:
- Share some folders between the various Windows servers, thus enabling their File and Printer Sharing feature on their NIC interface(s).
- Add a couple Firewall rules to allow traffic from both the LAN and VPN interfaces to any LAN destination.
- Open the Windows Firewall ports for file sharing (135-139 and 445 TCP/UDP), which can be easily done by allowing the File and Printer Sharing and File and Printer Sharing over SMBDirect apps to communicate through Windows Firewall (as shown in the screenshot below).
If we do all that, there's a high chance that we'll be able to connect to the shared folders without issues. However, there could be an edge-case scenario where, instead of accessing the shared resources, we'll be greeted by the following errors:
An error occurred while connecting to address \\<LAN-IP>\<SHARED-FOLDER>\.
The operation being requested was not performed because the user has not been authenticated.
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.
If you're getting one of the above error messages (or both) on one or more Windows machines, even if you've followed the above steps, there's a good chance you're also hitting that same issue.
These errors was caused by a non-trivial configuration issue that took some valuable time to fix; luckily enough, in my scenario, those two errors were both showing up, thus giving me additional hints. The second message greatly helped me to understand where the problem actually was because it led me to check the local group policies using the Local Group Policy Editor, where I eventually found this:
After looking at it, I immediately understood that the problem was due to the Guest account being A) enabled and B) blocked from accessing the local server from the network. As soon as I disabled the guest account, the "deny access" policy above automatically changed its status to "empty", thus allowing me to connect to the shared folders: problem solved!
Conclusion
That's it, at least for now: I hope that this small advice will help other system administrator that are looking for a way to fix their issue with shared folders while dealing with similar environments.
