If you read my last post, you'll know that the latest release of Windows 10 introduced an issue when connecting to public Samba shares. I showed you how this problem can be solved through the use of a local GPO. I thought that would be the last of my file sharing problems, but as usual I was sorely mistaken.
Recently, I had trouble connecting to a password protected Windows share from a Linux machine. I tried multiple ways of connecting to the share, double-checked settings, yelled at it, but nothing seemed to work. I was about ready to give up when I realized that the issue wasn't with Linux, but on how I permissioned the Windows share. Now it wasn't as simple as forgetting to add permissions to the share. It actually came down to the fact that I was relying on group permissions which most seasoned admins are accustomed to doing. And it wasn't just any old group that brought about this issue, but the default Local Administrators group in Windows that caused my latest headache.
Synopsis
What's Going On Here?
Normally, when administering permissions for a company, you want to give permissions to groups instead of individual accounts. This allows you to easily control permissions for different resources by just adding or removing users to and from a particular group. One group that's built-in to every Windows PC is the Administrators group. It gives any account in this group Admin rights to the machine. While for the most part this is still true, Microsoft introduced a security feature with Windows 7 called UAC which mitigates some of the outright power an admin account can wield.
You've probably seen a facet of UAC the last time you tried to install an application and a prompt invaded your screen to ask if you really, really, really want to install this application. Without UAC, this prompt would not appear and anyone with Admin rights would be able to run anything they wanted unabated, including people with more nefarious intentions. While this prompting is a beneficial security feature of UAC, it also causes problems when trying to give the Administrators group permissions to a Samba share.
If you give Samba permissions to the Administrators group, any attempts to connect to the share with an account in this group will fail. Your account will actually authenticate successfully with the host, but will automatically be kicked out by UAC because of its inability to prompt the remote user.
What Can I Do?
You have two options to get around this unexpected "feature". The reckless option would be to just disable UAC which I would strongly advise against. While UAC is a pain in the butt, it does provide protection against a lot of exploits. On top of the security aspect, starting with Windows 8, Microsoft has made it more difficult to completely disable UAC. In Windows 7, you can simply disable UAC in the Control Panel by moving the UAC slider all the way to the bottom. In Windows 8 and beyond, this only turns off some of the features of UAC and has no effect on the issue at hand. Trust me, I've tried. Instead, you need to either implement a Regfix or a GPO to completely disable UAC. I won't get into how to do this as I don't want you to be a lazy and dangerous admin even though that is my motto.
The correct and more often than not easier way to get around this problem is to create a brand new group and grant Samba permissions to it. You can create the group by launching the Computer Management (compmgmt.msc) console. Once the group is created, add any accounts needing share access to it. You can now allocate Samba permissions to this group instead of Administrators and save yourself a lot of needless troubleshooting.
If you're on a home network with just a single user, you can skip the previous step and give that sole user account permissions to the share and you'll be good to go. Keep in mind that under the Properties of the shared folder, the user or group needs to have the same permissions on both the Sharing and Security tabs. If the permissions are different, the least permissive of the two will take precedent.
Now that I'm at the conclusion of writing this article, I find it silly how simple it is to get around this issue compared to the amount of time I spent troubleshooting it. Either I need a vacation or a new brain...probably both.
: 
: