File Share in Windows Domain
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 5 hours ago
DavidDavid
214
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 5 hours ago
DavidDavid
214
Use security group ?
– yagmoth555♦
5 hours ago
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 5 hours ago
DavidDavid
214
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 5 hours ago
DavidDavid
214
asked 5 hours ago
DavidDavid
214
asked 5 hours ago
DavidDavid
214
asked 5 hours ago
DavidDavid
214
asked 5 hours ago
DavidDavid
214
214
Use security group ?
– yagmoth555♦
5 hours ago
add a comment |
Use security group ?
– yagmoth555♦
5 hours ago
Use security group ?
– yagmoth555♦
5 hours ago
Use security group ?
– yagmoth555♦
5 hours ago
add a comment |
3 Answers
3
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 4 hours ago
joeqwertyjoeqwerty
95.7k463149
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
3 hours ago
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
3 hours ago
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♦
3 hours ago
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 4 hours ago
Tim ListonTim Liston
4015
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
3 hours ago
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
1 hour ago
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
18 mins ago
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 3 hours ago
ivanivanivanivan
86536
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
3 hours ago
@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
3 hours ago
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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
3 Answers
3
active
oldest
votes
3 Answers
3
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 4 hours ago
joeqwertyjoeqwerty
95.7k463149
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
3 hours ago
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
3 hours ago
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♦
3 hours ago
add a 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 4 hours ago
joeqwertyjoeqwerty
95.7k463149
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
3 hours ago
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
3 hours ago
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♦
3 hours ago
add a 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 4 hours ago
joeqwertyjoeqwerty
95.7k463149
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 4 hours ago
joeqwertyjoeqwerty
95.7k463149
answered 4 hours ago
joeqwertyjoeqwerty
95.7k463149
answered 4 hours ago
joeqwertyjoeqwerty
95.7k463149
answered 4 hours ago
joeqwertyjoeqwerty
95.7k463149
95.7k463149
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
3 hours ago
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
3 hours ago
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♦
3 hours ago
add a 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
3 hours ago
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
3 hours ago
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♦
3 hours ago
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
3 hours ago
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
3 hours ago
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
3 hours ago
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
3 hours ago
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♦
3 hours ago
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♦
3 hours ago
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 4 hours ago
Tim ListonTim Liston
4015
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
3 hours ago
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
1 hour ago
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
18 mins ago
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 4 hours ago
Tim ListonTim Liston
4015
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
3 hours ago
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
1 hour ago
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
18 mins ago
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 4 hours ago
Tim ListonTim Liston
4015
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 4 hours ago
Tim ListonTim Liston
4015
answered 4 hours ago
Tim ListonTim Liston
4015
answered 4 hours ago
Tim ListonTim Liston
4015
answered 4 hours ago
Tim ListonTim Liston
4015
4015
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
3 hours ago
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
1 hour ago
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
18 mins ago
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
3 hours ago
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
1 hour ago
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
18 mins ago
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
3 hours ago
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
3 hours ago
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
1 hour ago
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
1 hour ago
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
18 mins ago
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
18 mins ago
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 3 hours ago
ivanivanivanivan
86536
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
3 hours ago
@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
3 hours ago
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 3 hours ago
ivanivanivanivan
86536
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
3 hours ago
@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
3 hours ago
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 3 hours ago
ivanivanivanivan
86536
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 3 hours ago
ivanivanivanivan
86536
answered 3 hours ago
ivanivanivanivan
86536
answered 3 hours ago
ivanivanivanivan
86536
answered 3 hours ago
ivanivanivanivan
86536
86536
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
3 hours ago
@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
3 hours ago
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
3 hours ago
@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
3 hours ago
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
3 hours ago
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
3 hours ago
@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
3 hours ago
@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
3 hours ago
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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♦
5 hours ago