Worldwide Locations
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 "under sharing" 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. But the best practices for setting permissions on Window Server are pretty simple, and following them can keep your permissions from getting messy and overly complicated while ensuring security.
A Short History of Windows Server Permissions
Let’s start with where share permissions came from. At 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.
NTFS permissions came with the introduction of the NTFS file system, beginning with Windows NT 3.1. Not everyone adopted NTFS right away though, instead opting for the more backward-compatible FAT and HPFS file systems. By the time Windows NT 4.0 came around in 1996, NTFS was finally taking root.
What are NTFS Permissions?
NTFS permissions allow for granular control for Microsoft Windows NT and later operating systems files; they allow users access to data at several levels. They allow access to individual users at the Windows logon on, regardless of their location or the network they are using. NTFS permissions can be set for:
- Full control. Users can add, change, move, and delete files and directories, as well as modify the properties of these files and directories. Users can also change the permissions for the files and directories. They can give others full control or take permission away.
- Modify. Users can view and modify files and their properties. They can add or delete files from a directory or add or delete properties from a file. But they can't grant permissions to other users.
- Read and execute. Users can read files and run executables, including scripts, but they can't change files and their properties.
- List folder contents. Users can view and list files and sub-folders and execute files. This permission is only inherited by folders.
- Read. Users can read or view files, their properties, and directories, but can do nothing else.
- Write. Users can write to a file, add files to a directory, and read files, but can do nothing else.
Limitations of Share Permissions
The share permission structure is hindered by many limitations.
It has only three levels of control.
- Read. Users can read or view files, their properties, and directories, and run some executables.
- Change. Users have all the permissions that come with Read, but can also modify the content of files and folders plus create and delete files and folders.
- Full Control. This is the same as NTFS Full Control. Users can add, change, move, and delete files and directories, modify the properties of these files and directories, and change the permissions for the files and directories.
Share permissions also lack granular control. Once permissions are granted at the share, those permissions apply files, folders, and sub-folders below that point. There is no way to be more granular and a lower level without creating yet another share.
What About the Authenticated Users Group?
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 replaced with Authenticated Users everywhere we see it. And the short answer is you can just ignore Authenticated Users in the share.
How Share & NTFS Can Allow Specific Access to Each Individual
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.
Share as Primary Access, NTFS as Secondary Access
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 into the lobby area. Anyone can enter that door, but inside that door is a security person or key card gate/turnstile/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.
The Problem with Adding Multiple ACLs to the Share
To address these sharing shortcomings, Microsoft originally told 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
- 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 "under sharing" concept from!)
The suggested best practice from Microsoft is to leave the share at Everyone – Full Control and diligently set your permissions on the NTFS folder. 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 than 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.
Does Granting Full Control at the Share Also Grant Permission to Manage the Share?
The answer is no. Giving someone Full Control of the share does not give them permission 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.
What’s the Last Word on Best Practices?
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!
