Confused on Share Folder vs NTFS Folder & File Access

DavidL2004

Hello guys,

I am really confused on the concept of apply share folder vs. NTFS file & folder access rights.
For example, when I created a shared folder called DATA. Automatically, everyone group is assinged as read only. on the NTFS it also shows User group as Read, List, execute.

If I need to create a group called SALES which will require the modify/write permission. Where do I add this group to??? Share folder or NTFS Permmission? Can I remove the everyone group from share folder access and users from NTFS Share? Please help. Thanks in advance.

sprkymrk

Share permissions only apply to users who access the share across the network (ie - from their workstation to a share on a server) while NTFS security applies locally AND across the network.

While Microsoft has their own way of doing this, most agree that the best practice (in most cases) is to set the share permissions to "Everyone=Full Control" and then set the NTFS Security to actually control access. This makes trouble shooting access issues much easier, and since NTFS applies whether they are local or remote, you still have the same level of security without the complexity of setting it in 2 different areas (Share + NTFS).

DavidL2004 wrote:

If I need to create a group called SALES which will require the modify/write permission. Where do I add this group to??? Share folder or NTFS Permmission? Can I remove the everyone group from share folder access and users from NTFS Share?

Depends on if you want the best way or the MS way. Also depends on if the share needs to be accessed by anyone other than SALES. Assuming that only the SALES group needs access, and assuming you start by creating a share called "SalesData" here are two ways you can do it:

1. Add the SALES group to the SHARE permissions, granting them Change permission. Then remove the Everyone group. On the Security tab, add the SALES group and grant them Modify rights. Remove the Users group.

However, now in the future, you will have to keep track of both Share and NTFS access as you add/remove/change access to the share. That is why most people will use method 2:

2. On the SHARE permissions, grant Everyone Full Control. On the Security tab, add SALES and grant them Modify. Remove the Users group.

Now you have the same security (remember that NTFS applies both locally and across the network), but when you need to make changes down the road, you do it all from the security tab, and don't worry about the Share permissions.

Hope that helps, and feel free to post back if you have more questions.

Ricka182

Okay, so above beat me to it...he probably has a better explanation than what I had anyway......

DavidL2004

Thank you so much sprkymrk. This really helps. No doubt MS has made it kind of confusing.
So let me see if I get this right?

NTFS vs Share Folder (The most restrictive applies)
NTFS group vs NTFS other group (They are accumulate unless there is a explicit right assinnged such as deny)

Is this correct? Tks again

Dave

sprkymrk wrote:

Share permissions only apply to users who access the share across the network (ie - from their workstation to a share on a server) while NTFS security applies locally AND across the network.

While Microsoft has their own way of doing this, most agree that the best practice (in most cases) is to set the share permissions to "Everyone=Full Control" and then set the NTFS Security to actually control access. This makes trouble shooting access issues much easier, and since NTFS applies whether they are local or remote, you still have the same level of security without the complexity of setting it in 2 different areas (Share + NTFS).

DavidL2004 wrote:

If I need to create a group called SALES which will require the modify/write permission. Where do I add this group to??? Share folder or NTFS Permmission? Can I remove the everyone group from share folder access and users from NTFS Share?

Depends on if you want the best way or the MS way. Also depends on if the share needs to be accessed by anyone other than SALES. Assuming that only the SALES group needs access, and assuming you start by creating a share called "SalesData" here are two ways you can do it:

1. Add the SALES group to the SHARE permissions, granting them Change permission. Then remove the Everyone group. On the Security tab, add the SALES group and grant them Modify rights. Remove the Users group.

However, now in the future, you will have to keep track of both Share and NTFS access as you add/remove/change access to the share. That is why most people will use method 2:

2. On the SHARE permissions, grant Everyone Full Control. On the Security tab, add SALES and grant them Modify. Remove the Users group.

Now you have the same security (remember that NTFS applies both locally and across the network), but when you need to make changes down the road, you do it all from the security tab, and don't worry about the Share permissions.

Hope that helps, and feel free to post back if you have more questions.

sprkymrk

DavidL2004 wrote:

Thank you so much sprkymrk. This really helps. No doubt MS has made it kind of confusing.
So let me see if I get this right?

NTFS vs Share Folder (The most restrictive applies)
NTFS group vs NTFS other group (They are accumulate unless there is a explicit right assinnged such as deny)

Pretty much it in a nutshell. It's been posted here before, but I'll repeat it for new comers.

Determine the LEAST restrictive share permission, based on user and group memberships.
Then determine the LEAST restrictive NTFS security, based on user and group memberships.
Compare NTFS and SHARE level permissions, and use the MOST restrictive.

Caveats, or exceptions, are that in general a deny trumps everything - except that an inerited deny will not override an explicit allow.

jasonboche

DavidL2004 wrote:

Thank you so much sprkymrk. This really helps. No doubt MS has made it kind of confusing.
So let me see if I get this right?

NTFS vs Share Folder (The most restrictive applies)

Well your wording is a bit off. What you need to evaluate is NTFS permissions COMBINED with Share permissions. That's where people get confused. And yes, the most restrictive permission applies.

DavidL2004 wrote:

NTFS group vs NTFS other group (They are accumulate unless there is a explicit right assinnged such as deny)

Again, it's not a matter of one groups permission versus the other. That would be easy to figure out. It's the permission for the combination of the two groups. And yes, in this case, these permissions are cululative, or additive. Pay special attention to DENY permissions. They will override granted permissions.

jasonboche

sprkymrk wrote:

an inerited deny will not override an explicit allow.

Really? I'm not sure about that. I will have to test that out in my lab. Albeit, that's a pretty hairy set of permissions to apply in a production environment which I would probably never implement.

Time to fire up the lab Oh wait, my lab runs 24x7. That's why my utility bills exceed my wife's monthly car payment.

royal

I'm 100% sure Mark is correct that an explicit allow will override an implicit deny.

blargoe

Mark's right, but hopefully you wouldn't see that much in production.

sprkymrk

blargoe wrote:

Mark's right, but hopefully you wouldn't see that much in production.

Amen to that. However, I have seen MS questions that will trip you up if you aren't aware of this little technicality. The standard trumpet that most instructors blow (including on the CBT Nuggets) is that a deny will always override allow. This is almost always true, except in the case mentioned above.

For further clarification, see my second post in this topic, the part about the Canonical Order of ACE's.

http://www.techexams.net/forums/viewtopic.php?t=22717

jasonboche

Lab test results were inconclusive because the full control group deny on the parent folder did not allow me to vew sub folders (and thus do anything) which had the user account explicit allow. So there's a caveat in the caveat.

Perhaps if I had used a less restrictive deny on the parent folder and a contra permission on the child folder, the test would have proved out. ie. on the parent folder, Group A is denied a file write/delete permission. On the sub folder, User A is explicitly allowed a file write/delete permission.

But I think it still points out in one particular case where effectively the deny on the parent is going to override the explicit allow on the child, short of creating a share directly to the child folder.

Good discussion guys. I'm always up for experimenting.

Jas

sprkymrk

jasonboche wrote:

short of creating a share directly to the child folder.

Very good point. In W2K3 AD, the "Bypass traverse checking" right is assigned to the Everyone group on workstations and servers. This means that the user can traverse a directory tree even though the user may not have permissions to the directory itself. It does not allow the user the right to list the contents of the directory, but they can traverse it. So yes, I believe you are correct jason, you would need a shortcut or share directly to the child directory in order for access to be granted.

A user right (such as bypass traverse checking) takes precedence over all file and directory permissions. We see this in the example of something like a user that has the right to perform backup operations (such as Backup Operators) even on files/folders that another user has set explicit deny permissions to the Backup Operators group.

Wow, this is getting deep....

However, here is an example straight from Microsoft for those interested:

Order of ACEs in a DACL

Microsoft wrote:

The canonical order also ensures that all explicit ACEs are processed before any inherited ACE. This is consistent with the concept of discretionary access control: access to a child object is at the discretion of the child's owner, not the parent's owner. The owner of a child object can define permissions directly on the child that modify the effects of inherited permissions. For example, suppose a parent object has an inheritable ACE that denies access to Marketing. And suppose the owner of a child object defines an explicit ACE that allows access to a subset of Marketing, let's say Bob. If the child object's ACEs are in canonical order, the explicit ACE that allows Bob access comes before any inherited ACE, including the inherited ACE that denies access to Marketing. During an access check, the operating system reaches the ACE that allows Bob access before it gets to the ACE that denies access to Marketing. As a result, Bob is allowed access to the object even though he is a member of the Marketing group. Other members of the group are denied access.

Double wow!

jasonboche

Last night I actually tried a START|RUN|<drive letter and path to child folder> and I got an access denied or folder doesn't exist error message.

Without testing, I do believe that creating a shortcut to the child folder would result in an error message because during the process of creating a shortcut, the shell checks to make sure the shortcut is valid and has correct syntax. If the START|RUN process can't see the child folder, the shortcut process will not either and thus I believe the shortcut creation process would fail.

Because of this, I do believe the only way to access that child folder would be through a direct share to it.

Mark, your quotations to TechNet do indeed indicate you are correct and I appreciate you digging them up.

sprkymrk

Okay - keep us up to date on your experiements jason. If I have time I'll do the same.

jasonboche

Sorry to mislead you but I don't think I'm going to experiment with this any longer. The scenario is quite ridiculous and we've already spent too much time on it. Plus, I know you have guns. Let's just say you're right and move on shall we?

sprkymrk

jasonboche wrote:

Sorry to mislead you but I don't think I'm going to experiment with this any longer. The scenario is quite ridiculous and we've already spent too much time on it. Plus, I know you have guns. Let's just say you're right and move on shall we?

Yeah, but Johan won't let me shoot other members in good standing.

sprkymrk

Okay - verified.

I created a Folder on a server share called "Test Folder". The top level share on the server is called "Admin" and is mapped as a V: drive in My Computer.

On Test Folder -
NTFS was set to Administrators=FC
TestGroup=deny FC

Inside I created a child folder called "SubFolder".
NTFS was set to Administrators=FC
TestUser=FC (TestUser is a member of TestGroup, but not a member of Administrators).

When going to the server and trying to access the share "Test Folder" as TestUser, I was denied access. I then created a shortcut on my desktop (by right click>New>Shortcut and manually typed in the path V:\Test Folder\SubFolder). I double click the shortcut, and voila!, access is permitted.

Cool.