Saturday, June 6, 2009

Active Directory Security Groups

Yesterday, during a Varonis training session, Paul Ezhaya started a great discussion by asking my opinion on strategies for naming security groups and organizing folders on file servers. The primary debate was whether to use security groups named after departments and roles or to use security groups named after folders that they provide access to. For example, if there was folder called Human Resources with sub-folders such as Employee Data, Forms, and Terminations, and folders specific to several departments how would we set this up from a security perspective? Would we create Active Directory groups based on Roles for the HR people who handle each department and then apply those groups to the corresponding folders on the file server? Or would we create AD groups named after the specific sub-folders and then add the specific people to those groups as needed? Along with the security groups we would take the lead in organizing the folder structure to match the security group naming conventions.

There is no “right” answer, but here are some of my thoughts on the Role versus Folder question.

In general, I prefer the Folder-based solution. The first reason is for the long-term security of your organization. Finding the data is always top priority so regardless of how you organize the folders; users will learn the taxonomy and adjust to it. You need to force the organization to apply security; therefore, if you organize the infrastructure in a secure manner, they won’t have to. Second, When you first set up your Role-based Security Groups you might have an accurate grouping of the users by department. However, over time people will not make the appropriate adjustments to those groups. After the initial setup fades away, when you add someone to a role-based security group to they can access a particular set of data, you may not realize what else that gives them access to. You may not it even give it any consideration because security will always be an afterthought. In a Folder-based solution, the security of the data is pushed to the forefront as the IT department knows what folders the Active Directory group gives them access to. And if the access is insufficient user will surely let you know, where the odds of them notifying you that they were given too much access in the Role-based scenario is highly unlikely.

Of course, we may have a hybrid approach. At the top level shares we might want to have security groups for the department and apply those at that level. Then we would turn off inheritance on folders with confidential data and apply the folder-based security to those folders. So we end up with a set of groups like this:


Where RO is for the group with Read Only privileges and RW is the group with Modify privileges.

If there are other reasons for you to use a Role-based strategy then I would highly recommend an automated Identify Access Management system. I think that you will still find that the default will be to provide too much access, but the results will be better.


  1. Hi, I googled this and have been using it this way as suggested. So far it has started to work out very well. It is much easier to identify what secuirty groups belong to what folders. Once they start to get setup it is much easier to add people to folders. Since most people when requesting access only say I need access to this folder, not their department name or any other info.

  2. Arthur,

    What would you about creating different shares for different groups with the similar access? So we would place sensitive data on one share and less sensitive data on the other share, then we can apply the permissions at the root level without braking the inheritance.

    please let me know,

    thank you,


  3. Anton,

    I am a fan of segregating data based on the sensitivity of the information. For example, if you had one share (the X: drive) for example, that everyone in the organization knew was for sensitive and confidential data and that sensitive data should not be stored on other shares, I think that would be a positive step.

    Although, that would be helpful in letting the system admins know where they need to direct their security enegry, it is not sufficient protection for the information without other ways to audit access to data.

  4. I find that Share Permissions are much better than using NTFS permissions for securing file access.
    The biggest issue with NTFS besides its highly-inefficient nature (I come from Netware where file level permissions were lean and equally effective) is "Owner/Creator" retaining permissions to files/folders even when the files are moved into a more restrictive area; of course, one could fix the NTFS permissions after moving, but that's not always done. Couple the inefficiency and extra effort required to the problematic command line tools that Microsoft has provided to modify NTFS permissions such as cacls.exe, xcacls.exe, and xcacls.vbs (they don't work as they should). Supposedly the latest tool icacls.exe works.

    If files need to be secured in a Microsoft shop, use share permissions. NTFS stands for Not That Flipping Secure.

  5. You can reduce the problem with the Owner retaining permissions by removing the CREATOR OWNER SID from folders.