0

As far as I understand, best practices recommend that security groups are used with a Windows domain to assign permissions over files and folders. That is, you should create groups in Active Directory, populate them with users, and then assign permissions to folders and files through the groups rather than individual users. I can see the benefits of this approach, BUT:

In my organisation we use a corporate information system for our daily operation. Every project and department are recorded into the system, and the system knows who belongs to each department and project. We are implementing a folder synchronisation mechanism by which the system can apply permissions to shared folders in our file servers to replicate our organisational structure. For example, if we have a "Sales" department with members Alice and Bob, the system will create a shared folder "Sales" and give it permissions for Alice and Bob. This works nicely, and has practically removed the need to manually assign permissions to folders and users.

The issue is that we are not sure whether Active Directory groups still make sense in this scenario. In principle, we assumed that one or more AD groups would be created for each department and project, and permissions assigned to it as usual. For example, there would be groups Dept-Sales-Head and Dept-Sales-Members, each with its own members, for the head and members of the Sales department, and permissions would be assigned through these groups. Our automated system is capable of creating and managing the AD groups. But we are afraid that we will end up with too many groups, as the number of organisational entities in our company grows. I seem to recall that it is not recommended to have over 5000 groups per domain, and it is very likely that we approach this number in a few years, so this approach would not be scalable.

The other option we are considering is to ditch security groups and have the automated system to assign permissions to folders using individual user accounts. This would remove the issue above, but we are concerned that a group-less security approach like this may have undesirable consequences that we cannot anticipate now.

So my question is: Does this group-less approach to filesystem permission assignment make any sense? Do you foresee any undesirable consequences in the long run?

CesarGon
  • 440
  • 3
  • 14
  • 27
  • 1
    `I seem to recall that it is not recommended to have over 5000 groups per domain`. There is no limit on the number of groups in a domain. There is a limit on the number of security groups a user account may be a member of. If your application doesn't need to use Active Directory groups, and people don't need to access documents outside the application, don't use them. – Greg Askew Dec 17 '18 at 15:21
  • The limit you're thinking of is 5,000 group members, not 5,000 actual groups. The number if group memberships per account is ~1000. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10) – Semicolon Dec 17 '18 at 17:02
  • 1
    you are going to have groups you're simply pivoting the management of those groups (E.G. sales department) from inside of AD to this other directory. Which solution will be easier to troubleshoot when permissions are wrong and users move from group to group? – Jim B Dec 17 '18 at 18:02
  • One potential downside to using groups that you should be made aware of is that in order for any changes in a user's group membership to take effect the user needs to log out. – Harry Johnston Dec 18 '18 at 04:16

2 Answers2

1

Does this group-less approach to filesystem permission assignment make any sense?

When designing an environment, Best Practice is the starting point from which one deviates given various business or technical reasons. If users may require access to a number of projects approaching 1,000 - it may qualify as a technical reason.

Given the current Active Directory Maximums (over 2 billion total objects; user group membership max of ~1000, and group membership maximum of 5,000), I believe that "we are afraid that we will end up with too many groups" is not a valid technical reason.

However, if the business has another application that can update access to files and resources based upon the users' role in the organization, (which is essentially what the nested AD security groups attempt to achieve), it sounds like a valid reason to justify skipping this particular best practice -- or at least noting it as achieved via other means. It is not as if you're discussing dropping groups altogether in Active Directory, just groups used to control access to File Shares.

Admittedly, if you're just going to be managing groups of similar composition in Active Directory anyway (Security Filtering for GPOs, Item-Level Targeting for Group Policy Preferences, User Rights Assignments on servers/workstations, delegated access to Objects / branches in Active Directory, AD- or LDAP-authenticated access to other applications or resources), then it may not make that much sense to drop groups for just this one thing. But, if I read your question properly, general access to resources in the Organization is different from controlled access to these "per-project" based file shares. Did I get that right?

Also, when reviewing assigning access to file shares these days, I always suggest looking at Dynamic Access Control.

Do you foresee any undesirable consequences in the long run?

  1. Unnecessarily long SACLs in the event the application doesn't also clean up entries for stale accounts.

  2. Unnecessary replication and larger or longer backups when no actual data changed because the ACLs on folders/files change more frequently than would otherwise be required with simple static ACLs.

Semicolon
  • 1,775
  • 8
  • 7
  • Thanks for your answer. Yes, we would still be using groups for group policy and similar things. Your point about larger/longer backups is a good one I hadn't think of, thank you. – CesarGon Dec 17 '18 at 21:34
1

First, automation is good. It's great you guys are trying to automate the management of these tedious things. However, I see two potential problems with trying to assign file permissions directly to users.

  1. Filesystem performance impact. Say you have a share with thousands or hundreds of thousands of files in it and you need to add or remove an employee's access to that share. Even if everything in the share's permissions are inherited from the root folder, the OS still needs to modify the ACL of every single file to update those permissions. With a huge share, that can both take a long time and reduce the performance of the file server while it's processing. With permissions applied to a group, there is zero impact because nothing is actually changing in the ACL.

  2. Performance issues with large ACLs. Admittedly, I have no idea what the symptoms of this might be. But I have to believe there would be negative consequences with having ACLs that have hundreds or more individual user entries. I'm guessing you'd see more latency from the client side as the server has to do more work to process the ACL. You'd also probably see higher load on the server itself requiring beefier hardware for the same task.

Ryan Bolger
  • 16,755
  • 4
  • 42
  • 64
  • Thanks for your answer. The issue of performance is a big concern, indeed. Thanks for pointing it out. – CesarGon Dec 17 '18 at 21:34