Windows has created a false premise that the best way to manage shared folder permissions is with groups. You grant access to the folder by way of an AD security group, then users request membership in that group. That's the way NTFS works but is it the way users think?
Users want access to a resource; they want access to a folder. They don't want membership in a group. Of course, they need membership in a group, but they don't know that. So, why would you force users to ask for access in such a roundabout way? It should be simple and the mechanism of how it is happening in the background shouldn't matter to your user. The premise is: users will think of what they want access to and should be able to request it directly.
EmpowerID File Share Manager puts a 360 degree view of file shares in front of your user. They can view what roles and/or groups they are a member of and see the resultant access to shared folders. Or they can view the shared folders they have access to and see the roles and or groups that make that happen.
And, most importantly, they can search on folders to request access. When they request access a few things happen unbeknownst to them. If they are allowed access directly, they are granted access. If a resource owner needs to approve access, it will route the approval to the owner and let the user know that it needs an approval before granting access.
EmpowerID does this by putting a user into a role which has access to that resource (shared folder in this case). By putting the user in a role and not an AD group it saves the user from being a member of too many groups and ultimately getting token bloat. Token bloat seems like a made up malady but it is bad. The more groups your user is in, the larger their token gets. At 1015 memberships, the token exceeds allowable size and the user cannot log in. As it gets over 256 memberships, authentication slows down and kerberos has a tendency to lock up with some applications.
So, by managing your shared folders with a dedicated self service portal, your users will have greater and easier access to shared folders, request access in a more intuitive manner, control harmful afflictions like token bloat, and reduce your dependence on an outdated technology like groups.
But you really don't stop there. That same self service portal can be used by the resource owners to see who has access to their resources (even if granted via groups the old fashioned way). They can grant and revoke access to their folders either by searching from the user or the resource. Most importantly, they can attest to the correct access from the resource side on a regular scheduled basis to meet auditing requirements.
Speaking of our friends the auditors, they might be even more resource oriented than the users. They need to track who has access to a resource and it costs you money and time to have them try to disentangle all of the resultant access from nested groups. Having them look directly at the resource is, after all, what they need.
Think about the problem of groups from their perspective. If a group is giving access to a shared folder, what happens if you're also using it for another purpose and people just keep getting added to it. Your auditing friend wants to be able to see that easily. EmpowerID solves that issue in another way, too.
We use hidden system managed groups and use them in a way that maximally reduces token bloat. The goal is to reduce the number of groups created to assign permissions and to completely control the membership of these groups so people can’t use them for other purposes and add members which would inadvertently grant access to the folders. We reject any outside additions or deletions of user to these groups.
The debate has raged for years on groups vs. roles, especially with regard to Active Directory and Windows permissions. The answer is easy: using groups is the old way; using roles is the new way. Using groups is letting the technology manage the way you do business. Using roles is making the way you do business lead the technology. Especially with shared folder permissions.