5

How do you assign a single user (or a couple users) to a shared subfolder but restrict it for others?

My company and I are running into an issue with how our current file share environment was setup but instead of trying to fix the problems, we're going to rebuild the system on a new platform. This time we want to do it right from the ground up.

However, the problem we're running into is how to get away from assigning a single user permissions to access the folder. My understanding is that you assign a user to a (security) group and then add that group to the NTFS permissions. However, we have a number of folders where we need to give a specific user access to the folder, but not the users in that group.

My apologies if I'm not explaining it clearly. I'll try to clarify as best I can in responses.

David
  • 157
  • 1
  • 1
  • 9

4 Answers4

7

My understanding is that you assign a user to a (security) group and then add that group to the NTFS permissions. However, we have a number of folders where we need to give a specific user access to the folder, but not the users in that group.

That's the general rule, but if you need to assign permissions to only a single user you can certainly do that.

Another option would be to create a Security Group, add this lone user account to the group and assign permissions to that group. That way if you need to grant other users access to the folder you can simply add them to the group.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • joeqwerty... thank you for your prompt response. Are you saying that it **IS** ok to include an individual to a group share? I've always been told that you _don't_ want to do that. But I think your second option would be the only way to go, however, I can see that getting ugly really quick. – David Jan 24 '19 at 00:17
  • 2
    It is OK if the situation warrants it. While best practice dictates that you should use Security Groups, it's not written in stone. – joeqwerty Jan 24 '19 at 00:27
  • 2
    As @joeqwerty says, best practice is to use groups to control access, then you can easily add/remove people from the groups as necessary. But it will work to also add individual users. The usual issue that when you start adjusting permission on that basis, you're more likely to forget what you've done - leave some account with access when you don't want to. If you document things well and if you're environment isn't too complex, it can work just fine to add individual users. – Ward - Reinstate Monica Jan 24 '19 at 00:43
  • Ward... I appreciate your input. I wonder if we can just implement a routine practice (maybe a monthly audit) to go scan through our shared environment for users to remove from shares? In thought it sounds good, in practice it might be a heavy administrative overhead. – David Jan 24 '19 at 17:27
  • @joeqwerty ... good point about it not being written in stone. Best practice is best practice. Not a hard and fast rule. – David Jan 24 '19 at 17:31
  • 1
    @David, make the best practice your 80/20 or 90/10 rule and implement exceptions when they're needed and justified. In this scenario you may very well be justified in implementing an exception. – joeqwerty Jan 25 '19 at 03:46
5

A general rule of thumb is if the folder is for a specific user, i.e. a Home drive folder or a specific confidential scanned document share, then set the permissions for the individual user.

If the folder is for a department or a program/application, then create a security group for the specific use and add the user(s) to the group and assign permissions to the group.

This method allows for expansion down the road when they decide they want additional people to have access and if you ever need to do maintenance in the future or re-create a share it will be straight forward to the people managing as to who should have access.

Tim Liston
  • 696
  • 3
  • 8
  • Tim, Much appreciated on the quick response. Currently, we're not using a "Home" drive but I have plans in the works to implement that. Just need the "go-ahead" from the people above. As far as the departmental shares go, I strongly believe in setting the permissions to a "department specific" group and adding the user to the group. But the issue I'm running into is with those few who are outside of the group, needing access to a specific subfolder (eg - IT needing access to \\..\HR\IT) and nothing else. How would I keep "IT" out of the rest of the HR folder but giving access to the one? – David Jan 24 '19 at 00:11
  • 1
    You can grant them access just to the IT folder inside the HR folder. By default, all users have the "bypass traverse checking" user right which allows them to traverse a folder for which they DO NOT have permission to get to a folder for which they DO have permission. The user simply needs to enter the full path to the folder, they CANNOT browse to the folder. – joeqwerty Jan 24 '19 at 02:20
  • 1
    I wouldn't suggest doing nested permissions like that. It gets messy and you tend to forget that there is a sub folder with unique (non-inherited) permissions. Instead you should try and convince them to create a new share called HR-IT, or whatever, and create a new group that grants both departments access. Once you allow nested permissions and unique folder security like that you'll be hard pressed to get away from it and more and more requests will come in for additional "unique" security. – Tim Liston Jan 24 '19 at 03:46
  • Tim... and that's what we're seeing now. A mish-mash of share concepts that have turned into chaos of share permissions. – David Jan 24 '19 at 17:30
5

From the Linux perspective and sharing via Samba I set the top level share to be 770 with the setgid bit set (so all files/directories created retain the group owners ship of the top level of the share), and give access there to the foo group. Then create a subdirectory, set the perms the same way, but also change the group ownership to a group unique to the user(s) that need access to the restricted area foo-admins or whatever. This maps nicely to your security groups in Windows.

The issue when assigning the perms to the specific user Bob is that when Bob retires/drops dead/wins lotto and a replacement is hired, you have to hunt down all the "special" stuff owned by Bob and change the ownership/perms.

So from a cross platform perspective, go with the security groups model and not individual users beyond their $HOME share or equivalent. Makes the inevitable personnel change much easier to deal with.

ivanivan
  • 1,448
  • 6
  • 6
  • ivanivan, Thank you for your advice on this. Currently, right now, we're not using Linux for file sharing, but that's a good thing to know down the line when/if we go that route. Much appreciated. – David Jan 24 '19 at 00:18
  • 1
    @David thanks. Important part is to keep the same principles in mind - use groups, not individual users when assigning rights that others may need/inherit. Doesn't really matter what you are using to share with, it is how you are sharing that counts. – ivanivan Jan 24 '19 at 00:33
2

One thing I learned on this thread is that we don't need to be so rigid with the "rules" when it comes to setting up shares and permissions, but adhering to best practices will save us trouble in the long run. Somewhere in the middle is the answer.

I wish there was a way to see how other companies handle this issue as I'm sure I'm not the only one who's faced it.

Thank you again for everybody's comments, advice, and suggestions - especially for not making me feel like a complete knucklehead. It's greatly appreciated.

David
  • 157
  • 1
  • 1
  • 9