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!

Related Courses

Upgrading Your Skills to Windows Server 2016 MCSA (M20743)
Securing Windows Server 2016 (M20744)
Installation, Storage, and Compute with Windows Server 2016 (M20740)

Subscribe

Never miss another article. Sign up for our newsletter.

 

In this article

Join the Conversation

12 comments

  1. Lee Reply

    What does this have to do with 2016? Same as 2012 or any other version me.

    1. Zane Schweer Reply

      “You are absolutely correct! These sharing techniques have been around for many years. What is surprising is how many students I run into who still do not understand the way sharing really works and the best way to manage them. What is new though is that Microsoft has changed their default settings and best practice guidelines to now match what many of us trainers have been teaching for years. You seem to have a good understanding of this already and are definitely ahead of the curve!” ~ Mark Morgan

  2. Howard Forder Reply

    Absolutely right on. I have been teaching this same method to clear up the confusion when combining share and NTFS permissions. Every week I ask the same question to whatever class I am teaching and they are all confused before I explain it as this article does. IT students are surprised and relieved to finally get a handle on this confusing topic. If I could find the author of this article, I would congratulate him/her. Way to go.
    -Howard Forder MCT for GK.

  3. Drew Reply

    I would like to strongly disagree with one point you suggested to give end-users, even management, the full permissions on NTFS permissions. And to add to that, leaving the “CREATOR OWNER” default permissions on most shares is a NTFS permission that should also be removed in most cases.

    Allowing end-users to be able to modify and set NTFS permissions can make an IT persons job very difficult. Even in the tech company I work for, end users always say “…I know how to handle file share permissions”… but it is surprising how untrue that is. If they remove administrator permissions our job will get very difficult, cut vs copy and paste, applying permissions to users not groups, etc etc.

    Yes, we can take ownership again but that can be very time consuming on large shares and if someone isn’t knowledgeable enough with permissions, subfolders may lose inherited permissions if they aren’t sure what they’re doing. I’ve even seen lots of issues with junior IT staff who apply the permissions you have suggested, then have to spend lots of time fixing their mistakes.

    If you’re managing a bigger network the comments you’ve mentioned break down after a while especially when you have to migrate file servers. In my opinion.

    1. Zane Schweer Reply

      Hi Drew,

      Thanks for the feedback on the article. Here’s Mark’s response:

      “As for giving Full Control on NTFS permissions, that is not my recommendation. I’m suggesting Full Control for Everyone on the Share, and then Full Control on the NTFS side only for Administrators (When warranted) and for the System Account. As for the Creator Owner account, that is actually something that can be very convenient when used properly. The reality is, MOST people who are interested in changing permissions on files will be the more savvy among the users out there. As such, even if you don’t give the Creator Owner Full Control of something, once you create a file or folder, you OWN that object. As the Owner, you can grant yourself Full Control if you know how. So, if you know how to set permissions on a file, you probably also know how to give yourself Full Control if you are the Owner.

      The Creator Owner object is really a template for giving the Owner of the object a higher level of permissions to something they own anyway.

      The great thing about NTFS permissions is that you can give a user Full Control to objects within “This Folder Only”, which means you can give them that Full Control without the worry of them giving themselves permissions throughout an entire subfolder structure. So, if the permissions are set correctly, you should be less fearful that one user ruins your day by completely changing an entire folder’s permission structure.

      Every environment is going to approach these things differently due to their needs, and more importantly any overarching security guidelines they must follow.

      This article isn’t intended to tell you that your approach to NTFS permissions is wrong. In fact, the article is mainly describing the fact that most organizations do not need to focus on Share Permissions at all, but SHOULD set those to Full Control for Everyone in most scenarios. Instead, attention should be focused on the NTFS permissions where you CAN set permissions at a much more granular level. Removing inheritable permissions where you see fit. Setting permissions that are NON-inheritable. Removing Creator Owner if that’s what you want. Using the new Dynamic Access Control Capabilities, etc.

      One thing I’ve found over the years (nearly 30) when working with Share and NTFS permissions is that rarely do I find any two organizations that do things the same way. Some do things the hard way (Crazy combinations of Share AND NTFS permissions combined), others are too relaxed (Full control for Everyone… EVERYWHERE), and still others take the middle road where the focus is on good, solid NTFS permissions providing Just Enough permissions to allow users to do their jobs.”

  4. Gary Reply

    Excellent guide – thank you very much for taking the time to write it.

    I have set up my structure this way and everything is working well with one exception – users have full control to folders they have created themselves. Users are given access to folders via AG groups and they only have modify permission. I can’t see any trace of authenticated users having anything more than modify.

    I have read that a solution to this problem is to give users read and change permission on the share but why is this not the preferred method? What are the down sides to just giving them change?

    Many thanks in advance.

    1. Zane Schweer Reply

      Thanks for your comment, Gary. Here’s Mark’s, the author, response:

      “When a user creates something, they become the owner of that resource. As the owner, they ALWAYS have the ability to change their NTFS permissions, but most end users don’t know how to do that. The Creator Owner special account acts as a Template of permissions given to a user on the items they create. My suggestion is to give Creator Owner Full Control, thereby giving the user Full Control automatically. Since the user is the owner, they have the ability to give themselves Full Control anyway. You could give the Creator Owner Modify, and that is the default permission a user would then receive to that which they create.

      Of course, ambitious users may discover they can assign themselves Full Control, but most won’t bother. In the event that it is important to know when someone changes their own permissions to something, Object Access Auditing should be set up to track that activity.

      It is possible to set Everyone to Change at the share level. However, this will apply to Everyone throughout the entire directory structure below the share and is inflexible. Many administrators struggle constantly with adding new entries on the share to address this issue when individuals wind up needing more than Change provides.

      So, no, it is not a best practice to have Change on the share. It should be a rarity that can instead be addressed with well managed NTFS permissions and auditing.

      This is just an opinion, but one that comes after 25+ years of working with Share and NTFS permissions. In the last 5 years or so, Microsoft has finally caught on and is singing the same tune. :-)”

      1. Gary Reply

        Thank you for taking the time to reply, this is much appreciated. I am setting up a complex file structure and appreciate your advice.

        1. Zane Schweer Reply

          You’re welcome. Let us know if there’s anything else we can help with!

  5. Gary Reply

    Hello,

    I’m really curious as to why giving change on the share could be inflexible. If Authenticated Users had change and Domain Admin had full control, would that not be all you require?

    As far as I can tell, if you grant change on the share with modify on Creator owner, users can still create and delete folders which is everything they need to do. They just can’t change permissions (well easily anyway) which for my scenario, we definitely wouldn’t want them to do.

    Can you give an example of how change could cause you a problem?

    To me, this seems to be an advantage over them having full control where they can potentially lock out Administrators, grant other users access, etc

    I know full control is the preferred method – I just don’t understand why.

    Many thanks in advance.

    1. Zane Schweer Reply

      Gary, here’s Mark’s response, “Giving ONLY Authenticated Users Change at the Share is inflexible. That means that even Administrators, or Managers or Executives who come in through that share are also similarly limited by that Change permission. If you did give those individuals Full Control somewhere in the NTFS permission structure, NOW you will also have to add them or their group to the Share with Full Control as well. So, it can be done, but it introduces more complexity and administrative overhead.

      And that is really the primary reason that we suggest Everyone – Full Control at the share level. This lets you focus on the NTFS permissions which can now be set up for different access at different levels of the directory structure without constantly needing to compare the NTFS and Share permissions with each other.

      As for allowing users to lock admins out…. Admins ALWAYS have the ability to take ownership, so that’s not much of an issue. And when it comes to users granting other individuals permissions to files, that can be handled by giving Creator/Owner Modify at the NTFS level of that folder, and enabling Object Access Auditing. This will keep most users at bay because they won’t know they have the ability to grant themselves Change Permissions on the file, and the auditing will track them if they do.

      All that being said, in doing a BUNCH of research on this, apparently there is a new “Built-in Account” that began with Windows Vista, but has not really shown up in much documentation. It is called ” OwnerRights” and is similar to Creator/Owner, but will instead strip the user of the ability to Change Permissions unless you explicitly grant that permission. I have not had time to test this fully myself, but my preliminary testing suggests that it will actually accomplish what you are looking to do. Just replace “Creator/Owner” with “OwnerRights” as the “Template” of permissions the user will receive. If you do not give it Full Control, the user should no longer have Change Permissions abilities. Test it out and see what you think. You should then be able to leave Everyone – Full Control on the share.”

      1. Gary Reply

        Thanks for taking the time to reply and also doing research. I’ll keep Creator Owner at Modify as like you say, this is the widely known method and best practice. I have Object Access Auditing enabled and even if they do manage to alter the permissions, it’s only really going to cause the owner an issue.

        Many Thanks