File Share in Windows Domain
Clash Royale CLAN TAG#URR8PPP
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.
network-share ntfs window-server-2012
asked Jan 23 at 22:56
DavidDavid
417
add a comment |
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.
network-share ntfs window-server-2012
asked Jan 23 at 22:56
DavidDavid
417
Use security group ?
– yagmoth555♦
Jan 23 at 22:58
add a comment |
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.
network-share ntfs window-server-2012
asked Jan 23 at 22:56
DavidDavid
417
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.
network-share ntfs window-server-2012
network-share ntfs window-server-2012
asked Jan 23 at 22:56
DavidDavid
417
asked Jan 23 at 22:56
DavidDavid
417
asked Jan 23 at 22:56
DavidDavid
417
asked Jan 23 at 22:56
DavidDavid
417
asked Jan 23 at 22:56
DavidDavid
417
417
Use security group ?
– yagmoth555♦
Jan 23 at 22:58
add a comment |
Use security group ?
– yagmoth555♦
Jan 23 at 22:58
Use security group ?
– yagmoth555♦
Jan 23 at 22:58
Use security group ?
– yagmoth555♦
Jan 23 at 22:58
add a comment |
4 Answers
4
active
oldest
votes
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.
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
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 at 0: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 at 0: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♦
Jan 24 at 0: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 at 17:27
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 at 3:46
|
show 1 more comment
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.
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
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 \..HRIT) 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 at 0: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 at 2: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 at 3: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 at 17:30
add a comment |
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.
answered Jan 24 at 0:08
ivanivanivanivan
92036
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 at 0: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 at 0:33
add a comment |
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.
answered Jan 24 at 22:34
DavidDavid
417
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f950471%2ffile-share-in-windows-domain%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
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 at 0: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 at 0: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♦
Jan 24 at 0: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 at 17:27
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 at 3:46
|
show 1 more comment
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.
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
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 at 0: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 at 0: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♦
Jan 24 at 0: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 at 17:27
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 at 3:46
|
show 1 more comment
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.
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
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.
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
answered Jan 23 at 23:13
joeqwertyjoeqwerty
96.1k463149
96.1k463149
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 at 0: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 at 0: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♦
Jan 24 at 0: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 at 17:27
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 at 3:46
|
show 1 more comment
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 at 0: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 at 0: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♦
Jan 24 at 0: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 at 17:27
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 at 3:46
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 at 0:17
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 at 0:17
2
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 at 0:27
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 at 0:27
2
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♦
Jan 24 at 0:43
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♦
Jan 24 at 0: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 at 17:27
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 at 17:27
1
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 at 3:46
@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 at 3:46
|
show 1 more comment
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.
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
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 \..HRIT) 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 at 0: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 at 2: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 at 3: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 at 17:30
add a comment |
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.
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
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 \..HRIT) 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 at 0: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 at 2: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 at 3: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 at 17:30
add a comment |
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.
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
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.
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
answered Jan 23 at 23:25
Tim ListonTim Liston
5516
5516
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 \..HRIT) 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 at 0: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 at 2: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 at 3: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 at 17:30
add a comment |
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 \..HRIT) 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 at 0: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 at 2: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 at 3: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 at 17:30
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 \..HRIT) 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 at 0:11
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 \..HRIT) 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 at 0:11
1
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 at 2:20
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 at 2:20
1
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 at 3:46
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 at 3: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 at 17:30
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 at 17:30
add a comment |
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.
answered Jan 24 at 0:08
ivanivanivanivan
92036
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 at 0: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 at 0:33
add a comment |
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.
answered Jan 24 at 0:08
ivanivanivanivan
92036
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 at 0: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 at 0:33
add a comment |
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.
answered Jan 24 at 0:08
ivanivanivanivan
92036
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.
answered Jan 24 at 0:08
ivanivanivanivan
92036
answered Jan 24 at 0:08
ivanivanivanivan
92036
answered Jan 24 at 0:08
ivanivanivanivan
92036
answered Jan 24 at 0:08
ivanivanivanivan
92036
92036
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 at 0: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 at 0:33
add a comment |
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 at 0: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 at 0:33
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 at 0:18
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 at 0:18
1
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 at 0:33
@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 at 0:33
add a comment |
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.
answered Jan 24 at 22:34
DavidDavid
417
add a comment |
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.
answered Jan 24 at 22:34
DavidDavid
417
add a comment |
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.
answered Jan 24 at 22:34
DavidDavid
417
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.
answered Jan 24 at 22:34
DavidDavid
417
answered Jan 24 at 22:34
DavidDavid
417
answered Jan 24 at 22:34
DavidDavid
417
answered Jan 24 at 22:34
DavidDavid
417
417
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f950471%2ffile-share-in-windows-domain%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Use security group ?
– yagmoth555♦
Jan 23 at 22:58