Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

It appears that there has been a subtle change in the way that share and NTFS permissions interact in Windows 2008 R2. In our application, we need to set the Write Attributes permission on in order to write to custom properties in OLE/DB documents. Under Windows 2003, setting the share permission to Modify would not conflict with this NTFS setting, but under Windows 2008 R2, we have to set the share permission to Full Control or the write to the custom properties will fail.

Please note that if I had my way, this would be fine. I consider share permissions to be poorly designed and there are other better ways to treat network and local users differently, if there is some need for that. But some of our customers have um, rigid, security policies.

share|improve this question
    
I am not aware of any documentation of what the share permission "modify" actually consists of. –  Helge Klein Jul 16 '12 at 9:13
    
I'm aware of some MS documentation for DFS that states minimum [very permissive] share permissions for that... it's in a 2k8 DFS context, not a 2k8 shares in general context, but would that be useful? –  HopelessN00b Jul 17 '12 at 15:09
    
Not DFS, but thanks. –  user1258221 Jul 18 '12 at 16:44
1  
Share permissions are an artifact from the FAT days where there were no filesystem permissions. They're best done away with via authenticated users - full control and dealt with at the NTFS level. –  MDMarra Dec 17 '13 at 18:02

1 Answer 1

I'm not sure what you are talking about here. There are no Share permissions called Modify in Windows Server 2003 and Windows Server 2008 R2:

Share Permissions


The interaction between Share permissions and NTFS permissions can be complex. Share permissions take a much simpler view of the world. Your granularity for Share permissions is limited to Full Control, Change and Read. There is no concept of a Share owner and no "Share permissions inheritance". To further complicate things you can have the same folder shared more than once, with each Share having independent permissions. If you have "nested" shares, you'll get the Share permissions of whatever shared you have mapped.

NTFS permissions are always enforced, even if a the user or process is remote. Windows will take into account both the Share Permissions and NTFS Permissions and "calculate" their effective permissions.

The general process is like this:

  • Gather all of the Share permissions and combine them together. A Deny will override any Allowed.
  • Gather all of the NTFS permissions the user has to the file. Make sure you account for both explicit and inherited NTFS permissions. Just as with Share permissions, a Deny will override any Allowed permissions. Remember to consider that NTFS permissions that are not inherited or explicitly assigned are implicitly set to Deny.
  • Combine the Share permissions and NTFS permissions. Where there is an overlap the more restrictive of the set is the effective permission.

You are probably seeing a more restrictive interpretation of Modify (or Change?) in Windows Server 2008 R2 which is then calculated against your less restrictive NTFS permissions. I like @Helge Klein could not find any documentation on what constitutes actual atomic permissions of the Modify Share "meta-permission".

As you have discovered, this process is complex and prone to errors. Make your life simple and use NTFS permissions exclusively for your access control. Set your Share permissions so they are wide open (DOMAIN\Authenticated Users - Full Control) and then set the NTFS permissions to provide you desired access control - something like the following is typical:

  • DOMAIN\Authenticated Users - Read
  • DOMAIN\Accounting-Users - Modify
  • DOMAIN\IT-Admins - Full Control

The Access Token the user or process ends up contains the more restrictive ACLs and not just a union of then. This is the only sane way to do it otherwise you have to maintain and troubleshoot your ACLs in two separate spots with two separate set of tools. That way lies the path of madness.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.