When share permissions and NTFS permissions are not equal what happens?
|
Another article I wrote as a guest blogger for Intense School, partly based on one of my previous Blogs posted a few months ago, I altered it slightly. It’s easy to get lost in the share vs NTFS permissions maze, especially when the two get combined creating shared folders, 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. Having said that… Show Although the basic shared folder functionality changed slightly over the past few years (especially with the introduction of Server 2012 not to long ago) the whole share vs NTFS permissions ‘debacle’ hasn’t gone away and still raises some questions every now and again. More often then you think people get confused with the mix and match process when applying these permissions, let’s clear up a few misconceptions shall we?! Shares on 2012 I assume we all know how to share a folder right? Although the creation process is slightly different depending on the OS used, most of the differences come from the graphical user interface and not from new technology per see. However, Windows Server 2012 might be the exception here… Mainly because of the new and improved SMB 3.0 protocol additional steps and features have been added to the shared folder creation process. First you may need to 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 the options: Quick, Advanced or Application. Depending on the profile you select different functionality becomes available like: General file sharing, Quota’s, Data Classification, Sharing functionality for SQL Databases or Hyper-V environments, Clusters included and more. In the steps that follow you can choose to apply Access Based Enumeration or enable Encryption and Caching. Long story short, stuff to be aware of before you start. But I’m drifting, lets get back on topic.  Rights vs Permissions Easily get mixed up… But note, they are (very) different. Rights get applied, mostly through Group Policy, to Organizational Units which might hold different AD objects like: User Accounts, or groups of users, Computer Accounts etc… It’s something the user has a right to do, examples are: System Shutdown, install software, logon interactively, logon through Terminal Services, run a Batch job… you get the point. Permissions apply to files and or (shared) folders in most cases, but also to printers, shares, registry keys and more. Permissions are set in Access Control Lists (ACL’s). 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 whoever 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 for the simple reason being, it offers no other way. Remember, as mentioned above, this only applies if these folders are accessed over the network, not locally. But let’s not go into any further detail regarding FAT32, because, well… why would we? 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, if you want to or not # 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 allow 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, read on. Share permissions more specific When creating shared folders there are three different share permissions that can be applied to a user or groups of users # READ – Allows users to read files and list the contents of folders and volumes. 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 CONTROLL – 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 get 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 it’s account but is also member of Group-A which has Change permissions applied to it. NTFS works a bit differently as apposed 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 connection to a shared folder you should do the following:
Keep it simple It’s considered a 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 when accessed over the network the most restrictive permissions get applied, 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, 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 all the appropriate boxes on the left will be checked showing you which permissions are currently applied to that 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 alike to create and manage folders etc… Although there are multiple ways in setting up these kind of structures, and better ones for sure, I’ll keep it simple to give you an idea on the possibilities and possible pitfalls. By default, when an Administrator creates a sub folder within a shared folder this folder will inherit the NTFS permissions from it’s parent folder, being the shared folder. Hmmm nice sentence. 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 to 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 but 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 in where we mix and match Share and NTFS permissions especially when inheritance come into play, 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 below, and so on. 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, give it a Google. Have a look at Microsoft DFS as well, a great solution but a whole other Blog subject on itself. I’m not too familiar with all that’s out there but I recently used Microsoft iCACLS when bulk applying / changing NTFS permissions, 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, as always. Bas van Kaam © Reference materials used: TechNet.com
Bas van Kaam Field CTO EMEA by day, community by night @ Nerdio Father of three, IT professional, freelance/independent blogger/analyst, Co-author of the book Project Byte-Sized and author of the book: Inside Citrix – The FlexCast Management Architecture, over 400 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast: above-average runner (look me up on Strava) 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant. What happens when share and NTFS permissions combined?When you share a folder on an NTFS volume, both shared folder permissions and NTFS permissions combine to secure file resources. Shared folder permissions provide limited security for resources. You gain the greatest flexibility by using NTFS permissions to control access to shared folders.
Why combining NTFS and share permission are significant in window server configuration?The main advantages of NTFS share permissions are that they affect both local users and network users and that they are based on the permissions granted to an individual user at the Windows logon, regardless of where the user is connecting from. There are both basic and advanced NTFS permissions.
Are share and NTFS permissions cumulative?Rules for Determining User Access
If a file system object is accessed through a share, NTFS and share permissions are merged and the most restrictive permission level wins. A user's individual and group membership permissions (if applicable) are merged additively, producing a cumulative effect.
How would you determine the effective permissions when both NTFS permissions and share permissions are applied?How would you determine the effective permissions when both NTFS permissions and share permissions apply? You look at the most permissive permission on each and then compare NTFS and Share look at the most restrictive of the two sets.
|
