Best Practices for Share Permissions in Windows Server 2016

Most of us have heard of “oversharing” in the social sense (i.e. giving out too many details of your personal life), but how about “undersharing” in the Windows Server realm? What does that even mean? Well, I sort of just made that up, but it does actually make some sense when you think about it in terms of creating a Windows Share that doesn’t provide enough permissions.

I shouldn’t be surprised that some folks are still confused about the best way to handle Share and NTFS permissions. Microsoft hasn’t made it very easy by relying on course developers and exam writers to inject their own opinions on the matter instead of following a set standard. However, us old-school Windows Server trainers have been touting our own “best practice” scenario for quite some time. Microsoft has finally caught up with us.

Let’s start with where Share permissions came from. In the beginning of Windows networking and creating Shares, there were no NTFS permissions available. The file systems were FAT16. Since the file system had no underlying permissions available, the only way to secure access to the content was to have permissions on the entry point to the file system, which is the Share.

Unfortunately, the Share permission structure is hindered by many limitations. First, there are only three levels of control: Full, Change, Read or just provide no access to the share for an implicit fourth level of control. Second, once permissions are granted at the share those permissions apply files, folders and subfolders below that point. There is no way to be more granular and a lower level without creating yet another share.

All of these issues were solved with the introduction of the NTFS file system beginning with Windows NT 3.1. Not everyone adopted NTFS right away though and instead opted for the more backward-compatible FAT and HPFS file systems for a period of time. By the time Windows NT 4.0 came around, NTFS was finally taking root.

Another issue is that of the “Everyone” account. Beginning with Windows NT 3.1, up through Windows NT 4.0, the Guest account was automatically enabled. As part of the Everyone group, even Guests were granted the same access as authenticated users wherever Everyone is found on an ACL. In Windows 2000, the Guest account was disabled by default, but the Internet Guest account came into play and was enabled out of the box on Windows 2000 Servers AND Windows 2000 Clients. The Internet Guest is also a member of Everyone.

To address this problem, Microsoft introduced the Authenticated Users group to differentiate between Guest and Non-Guest users. This is the reason why you find so many people using Authenticated Users on Share permissions instead of Everyone.

Fortunately, in modern versions of Windows Client and Server (beginning with Windows Server 2008), the Internet Guest account is no longer an issue, and the Guest account is still disabled by default. This means that the default Everyone account we find on a Share does not need to be urgently replaced with Authenticated Users everywhere we see it.

Unfortunately, many organizations still manage their Shares as if it is 1995 (some 22 years hence at the time of writing). That would be the equivalent of using a pay phone in today’s universal cell phone era. So, it’s time to modernize that approach to Share permissions just as we have embraced the age of always-on mobility.

I can sum up the approach in one sentence: Set Everyone – Full Control on the Share, and focus on granular permissions through NTFS. (See, that was easy!)

But, wait…how is it that Everyone is OK at the share? Isn’t that a security hazard?

Not at all.

Even though Guests are no longer involved, it is true that Everyone includes all authenticated users from the entire Forest (just like Authenticated Users by the way). However, we can think of the Share as the door to a vestibule or lobby area. In many organizations with a large corporate facility, you will have a door to get in to the lobby area. Anyone can enter that door. But, inside that door is a security person or key card gate/turnstyle/door that only authorized users can go beyond. Well, that second layer is just like the NTFS permissions we use in a file system.

Just imagine that we said only salespeople can come into the lobby even though the building has offices for the engineering, IT and management folks as well. That’s what a share does. If a share is more restrictive than the NTFS permissions, even if lower level folders and files allow access, the share would take precedence. So, in the office scenario, your keycard would let you in the door if you are part of sales, but you couldn’t enter the lobby as a non-sales individual even if the inner security would let you pass.

Over the years, to address these Sharing shortcomings, Microsoft taught people to add multiple ACLs to the Share, mirroring what is set on the NTFS folders. This can create a complex and confusing assortment of permissions. The algorithm for calculating those permission interactions is: Total the cumulative permissions on the NTFS side, then total the cumulative permissions on the Share side. Whichever of the two is more restrictive becomes the Effective permission.

Take the following scenario, for instance.

There is a folder called E:\SalesData on a server that is shared as SalesData. Joe is a member of Sales and Management. On the NTFS folder, Joe has Read as a user, Modify from Sales and Full Control from Management. On the Share, the only entry is Sales with Read. When Joe attempts access to the folder, he can only Read the data because the Share permissions are more restrictive. (Now you see where I’m getting the “undersharing” concept from!)

Now the suggested best practice from Microsoft is to leave the share at Everyone – Full Control and diligently set your permissions on the NTFS folder. (It’s about time since I’ve been preaching this for 20+ years!) So, in our previous scenario, if we change the Share permissions to Everyone – Full Control, Joe will now have full control of the folder as he should since he is a manager. However, if Jane accesses the folder and is only a member of Sales, she will only get Read permissions since her NTFS permissions compute to Read and are more restrictive that the Everyone – Full Control from the share. If Bob comes along and is not a member of either group, he gets nothing. Nada. Zilch. Very simple, very easy to manage and very secure if you do your homework on the NTFS permissions.

And NO, to answer your inevitable question. Giving someone Full Control at the Share does NOT give them permissions to manage or do anything TO the share. You can only control a share if you are an Administrator or Server Operator on the server where the share exists.

So, the bottom line is, go ahead and overshare on your Share permissions. It’s OK. Nobody will think any worse of you for it. In fact, it may simplify your life as an Administrator to the point where you actually have time to do some of that oversharing on your social media for a change!

Never miss another article. Sign up for our newsletter.

Please support our Sponsors here :

Related Courses

Subscribe