It’s so easy to get lost in the share vs NTFS permissions maze, especially when the two get combined creating shared folders, which is the main focus of this article. Not a new topic by any means, but still definitely one worth mentioning. I’ve seen multiple medior and even senior admins struggle with this, and unfortunately it’s not as ‘basic’ as everybody thinks. Although I’m not the first to touch the subject and I’ve also seen and read multiple blogs discussing the matter, I think we can still find new ways around this predicament. Let’s jump right in…

Although the basic shared folder functionality has evolved slowly over the past few years (especially with the introduction of Server 2012 not too long ago), the whole share vs. NTFS permissions ‘mechanism’ hasn’t changed and still raises some questions every now and then. People get confused with the mix and match process more often than you think when applying these permissions. Let’s clear up a few misconceptions, shall we?

Sharing in Windows Server 2012

I assume we all know how to share a folder, right? The creation process may vary depending on the underlying Operating System (OS) used; this is mainly because each OS uses its own graphical user interface (GUI), each being slightly different from the next. Having said that, Windows Server 2012 might be the exception here…

Not only is the GUI again different from the others, additional steps and features have also been added to the shared folder creation process primarily because of the new and enhanced SMB 3.0 protocol involved.

Let’s break it down: First you decide if you want to create an SMB or NFS shared folder (if the NFS service is installed). Next you’ll need to choose a so called ‘Share Profile’. For example, when creating an SMB share you have these options: Quick, Advanced or Application. Depending on the profile you select different functionalities become available, like: General file sharing, Quotas, Data Classification, Sharing functionality for SQL Databases or Hyper-V environments, Clusters included and more. Once that’s done you can apply Access Based Enumeration or enable Encryption and Caching. Long story short, these are things to be aware of before sharing out folders. But I’m drifting, let’s get back on topic.

Rights vs Permissions

You can easily get mixed up with the two, but note that they are (very) different. Rights get applied, mostly through Group Policies, to Organizational Units, which can hold different Active Directory objects like: User Accounts, groups of users, Computer Accounts, etc. It’s something the user has a right to do, and some examples are: system shutdown, install software, logon interactively, logon through Terminal Services, run a batch job… you get the point.

In most cases permissions apply to files and/or folders, but they can also apply to: printers, shares, registry keys and more. Permissions are set in Access Control Lists (ACLs). A single entry is referred to as an Access Control Entry (ACE). Preferably, use groups of users as opposed to a single user whenever possible.

Share Permissions in General

To start, share permissions are only applied when a shared folder is accessed over the network. Keep that in mind because it’s a common misconception to think otherwise. When an Administrator or someone else logs in locally on the machine (and this can be a standard desktop just as easy) from where the folder is shared, NTFS permissions apply, or in the case of an FAT32 file system, no permissions get applied. No matter how restrictive the shared permissions might be, it’s NTFS above all. NOTE: This also goes for Terminal Server (RDS) environments with published Hosted Shared Desktops!

FAT32

But what if we use a FAT32 file system? I haven’t seen one in years but ok… Share permissions are, or were, often used to control access to folders on a FAT32 file system because there’s simply no other way. Remember, as mentioned above, this only applies if these folders are accessed over the network, not locally.

Hidden

Shared folders can be made hidden by adding the $ sign at the end of the share name, like: sharedfolder$. This way it’s still accessible if you have the proper permissions, just not visible by default. You’ll have to use the full share name, $ sign included.

When you install an Microsoft Server Operating System it automatically creates several hidden administrative shares, whether you want to or not. Here they are:

  • * Admin$ – This is the system root, usually C:\Windows. Administrators are assigned Full Control share permissions.
  • * C$, D$, E$ – Each volume on a hard disk is shared by default and provides easy access of the entire volume to Administrators. Administrators are assigned Full Control share permissions.
  • * IPC$ – Allows named pipes connections.
  • * Print$ – Created when printers are shared and allows clients to automatically download the printer drivers.


NTFS

When creating a shared folder on an NTFS file system, you need to apply at least Read NTFS permissions on the same folder (although it’s shared, it’s still just a normal folder like any other) for a user to able to access it. Regardless of the share permissions given, it’s always a combination of share and NTFS.

More Specific Share Permissions

When creating shared folders there are three different share permissions that can be applied to a user or group of users:

  • * READ – Allows users to read files and list the contents of folders and volumes. It allows executing of applications as well. The default for new shared folders is Read permissions for everyone.
  • * CHANGE – Same as Read and allows the user to modify, create and delete files and subfolders.
  • * FULL CONTROL – Same as Change, but additionally allows the user to modify permissions.


The Combination

This is where it gets a bit more complicated. When you create a shared folder you apply share permissions and NTFS permissions (Read at a minimum) – we’re clear on that. Next, how do we determine the effective permissions on the shared folder?

Simply put, you take the applied share + NTFS permissions and the most restrictive of the two gets applied. For example: if you grant User-A Read share permissions and Full Control NTFS permissions, the most restrictive one will come out on top which is Read: meaning that the user, or group of users can’t create, delete or rename folders but just read and browse through them. The opposite is also true, when you grant User-A Read NTFS permissions and Full Control share permissions it’s still the Read permission that gets applied as being the most restrictive.

Effective NTFS

Before determining the effective permissions (most restrictive) on a shared folder, you first may need to determine the effective NTFS permissions. In the example above I used a single user, nothing more. But what if that user is also a member of a group which has different NTFS permissions applied to it?

Another example: User-A has Read NTFS permissions applied to its account but is also a member of Group-A, which has Change permissions applied to it. NTFS works a bit differently as opposed to share permissions. When comparing NTFS permissions the least restrictive get applied, in this case that would be Change!

When it comes to share permissions you typically would allow a group certain share permissions and deny the same permissions to certain members of that group, if there’s no other way. So to determine the effective permissions when connecting to a shared folder, you should do the following:

  1. Determine the effective NTFS permissions.
  2. Determine the effective share permissions.
  3. Take the more restrictive of the two.

Keep It Simple

It’s considered best practice (although debatable) to apply share Full Control permissions to a shared folder and then use NTFS permissions to further lock down access when and where necessary.

Simply take a group of users, grant them Full Control share permissions and apply Read NTFS permissions on the same shared folder. This way the most restrictive permissions get applied when accessed over the network, Read NTFS. And remember that when accessed locally only NTFS permissions get applied, so no matter how the folder is accessed, over the network or locally, Read permissions will get applied.


Keep in mind that when you use the Microsoft Effective Permissions Tool, share permissions are not part of the calculation! So don’t use it to determine the effective share permissions, but for NTFS it’s fine of course.

Click the ‘Advanced’ button from the ‘Security’ tab, see above, next choose the ‘Effective Permissions’ tab. Fill in a username; you need to use the ‘Select’ button on the side. Once entered, some, none, or all boxes on the left will be checked showing you which permissions are effectively applied to that specific user account.


Inheritance

What we’ve discussed so far all applies to the shared folder itself, which permissions you have or don’t have, within that particular shared folder. Your effective permissions on the shared folder determine if you, for example, can create, rename or even delete folders, to name a few. In most cases ‘normal’ users will have Read permissions and Administrators will have Full Control or something similar to create and manage folders, etc. Although there are multiple ways to set up these kinds of structures, and better ones for sure, I’ll keep it simple to give you an idea of the possibilities.

By default, when an Administrator creates a sub folder within a shared folder, this folder will inherit the NTFS permissions from its parent folder, it being the shared folder. It doesn’t do anything with the share permissions. So when ‘Everyone’ or your ‘Domain Users’ have effective Read permissions on the shared folder, it’s important to know the combination of permissions that are applied. Here’s why:

Remember that the effective permissions that get applied on a shared folder are the most restrictive found, see above. If you apply Full Control share and Read NTFS permissions, the sub folders created by your Administrator will inherit the Read NTFS permissions — not too bad, right? But if your effective Read permissions come from a combination where you grant Read share and Full Control NTFS permissions, the same rules apply. The newly created sub folders will inherit the Full Control NTFS permissions, meaning that your shared ‘root’ folder is still safe because only Read permissions get applied. The sub folders now have the inherited Full Control NTFS permissions, not something you want and that’s an understatement.

Conclusion

Although my example above perhaps isn’t that realistic, it does give you an understanding on how permissions work. I can probably think of another dozen examples where we can mix and match share and NTFS permissions, especially when inheritance comes into play. That’s not to mention all the sub permission combinations that we could apply using the ‘Advanced’ security properties button, which is also used for disabling and enabling inheritance by the way, see screenshot below.

A lot of companies have their own Permission and Rights management protocol to follow, which is a good thing if you ask me (most of the time anyway). Think about how in your situation inheritance can assist you and have some fun playing around in your test lab. Try different folder structures, break inheritance from the root (shared) folder and start applying permissions from one or two level below, etc… Just give it a go!


There are also some great toolsets out there that can assist you in creating your folder structures and applying permissions, some of which you may need to pay for and some for free, just give it a Google. Have a look at Microsoft DFS as well, a great solution but a whole other article subject on itself. I recently used Microsoft iCACLS when bulk applying/changing NTFS permissions, and it worked very well.

As a last reminder and take away from it all, remember that when discussing folder security, don’t use rights where you mean permissions and vice versa. These two get mixed up… A lot! Let me know what you think; all comments are welcome.

References:

www.technet.com

www.microsoft.com

www.techtarget.com

www.basvankaam.com