Sharing Security Driving me nuts? Please help

[SBSP]

I bought a new file server to replace the current one.

On the old server users were added to shares randomly no using groups and quick fixes were used by taking off permission inheritance and some users even had "change permission" permission


So i'm starting from scratch resetting all the permissions.
We have about 60 Users, and if you add too many users to a share it starts to not load the display names properly when looking at the list of permissions it just shows Active Directory ID numbers instead.

This is what i want to do for each shared drive.
I have created a M_Drive$ share which people map to by use of a normal logon script.

I then removed Everyone from the list and created 2 Security groups on AD
One is called "Mdrive Read only" and the other one is called "Mdrive Read/Write"
And added users to the security group accordingly

On the share permissions i have added the above mentioned security groups.
And the same under the security tab making all its sub folders inherit permissions from the Mdrive shared folder.

The problem is it seems like the 2 security groups are ignored and do not apply.

It only works if i add the actual user to the Share permissions and Security permissions.
It also works if i add OU's

The only time the 2 security groups take effect is if i add "everyone" to the share permission and then the security group to the security permissions, This is not what i want because the users which are not members of my 2 security groups will then have access to resources which they cant have, also new users will automatically have access and cant add all users to the group cus then i have to manage it every time we create a user.

Seesh! Can someone please please help.

 

[K3NS31]

Well, standard practice always used to be to basically ignore sharing permissions (by giving "everyone" full access) and then use NTFS security permissions to control who actually has access and what their access will be. (This way you avoid your current problem of "are my share permissions and ntfs permissions conflicting with each other?" {hint: probably, hence it's not working the way it's supposed to}
Then if you have users who shouldn't have access to the share, you take them out of the ntfs permissions. Or even put them in with "deny" permissions if you're paranoid.
Also, as you are doing, use groups to control who has access, so if u have users who shouldn't have access, make a group for them too. Add it to the ACL as 'deny'. Problem solved.

 

[SBSP]

I get what you are saying and i have done and tested it like that, it works
But this creates too much maintenance, cus if i create new users i have to remember to add them to the deny list cus the share "Everyone" has full access.
Also we have about 5 drives so the person is not allowed to have access to the Mdrive may have access to the SDrive.

Unleass i try to create 4 security groups for each share.
2 for the actual share and 2 for the security permissions.

Going to try that quickly.

 

[SBSP]

Well, standard practice always used to be to basically ignore sharing permissions (by giving "everyone" full access) and then use NTFS security permissions to control who actually has access and what their access will be. (This way you avoid your current problem of "are my share permissions and ntfs permissions conflicting with each other?" {hint: probably, hence it's not working the way it's supposed to}
Then if you have users who shouldn't have access to the share, you take them out of the ntfs permissions. Or even put them in with "deny" permissions if you're paranoid.
Also, as you are doing, use groups to control who has access, so if u have users who shouldn't have access, make a group for them too. Add it to the ACL as 'deny'. Problem solved.

I removed all permissions from the Security tab and only added the 2 groups allowed read/write access and the other group which is read only with users.
And it works fine without having to change things on the Security tab.

Dont know why i never thought of that.

Thanks for the help.

 

[K3NS31]

no prob