Monday, October 26, 2009

Active Directory Security - Rights Assignment - Permissions for Shares and Folders

In my previous posts, I explained how much it bothers me to have to assign rights to a resource more than once. I already spoke about about assigning rights to computers and servers here. Now, I would like to discuss my preferred method of assigning rights to objects (files/folders/shares/etc.).

The first thing I do when I am assigning rights to a folder is create a series of 'Domain Local' groups (If I remember correctly, your domain needs to be at a certain functional level in order to use 'Domain Local' groups. So, if you have any problems assigning 'Domain Local' groups, you may want to check out what functional level you are at.) for each type of permission I think I will ever grant to the object (Use Domain Local groups because they can contain Global groups from any Domain). Then, I assign 'Roles' ('Global' groups) to the appropriate 'Domain Local' groups in order to grant access to the object. Here is an example:

For this example, I am setting permissions on the 'Software' folder (happens to be a share also) on a the server PROVO-FS1.

I start by creating at a minimum the following 'Domain Local' groups:

PROVO-FS1.Software.Read
PROVO-FS1.Software.Write
PROVO-FS1.Software.Modify
PROVO-FS1.Software.Full

You can extend this to other more specific permissions if you feel you will use them (e.g. PROVO-FS1.Software.ListFolder). You can also use these same groups to add permissions to the share. Just make sure you assign the appropriate share permission for the groups as there is not a 1-1 relationship between share and NTFS permissions.

Then, you add these rights to the 'Software' Share/Folder. Make sure you review the default rights and remove groups that should not have access. You can remove all groups, but some prefer to leave the local administrator and/or 'Domain Admins' accounts. The main concern here is to make sure you do not, unknowingly, leave ACLs that will grant users higher privileges than they would otherwise gain through these new groups.

Once you are done creating the 'Domain Local' groups, you can add 'Global' groups (Roles) to the 'Domain Local' groups. (e.g. you may want to add the 'Global' group 'Information Systems Users' to PROVO-FS1.Software.Modify or add the 'Global' group 'Software Developers' to PROVO-FS1.Software.Read.

Now, here are some rules that must be followed (Ok, they are rules that I made up, but I like to follow them).

Rules
Rule #1 - 'Domain Local' groups can never include 'User' objects. You can only assign 'Roles' ('Global' groups) to 'Domain Local' groups. Then, you assign 'Users' to 'Roles' ('Global' groups).

Rule #2 - Do not use the 'Full' (Full Control) group unless you want the group you are assigning here to be able to modify security permissions (very few people). The 'Modify' group has all of the rights anyone should need to manipulate, rename, delete, etc. Full Control is by far the most misused permission and it is a very bad security practice to grant this permission to users other than system administrators or business owners. However, if you are using the method of assigning rights explained in this post, you can easily delegate control of the groups to business owners or develop an application that allows them to modify group membership. So, you would not grant 'Full' to the business owner.

You may also want to extend the validation of rights further up the tree. For example, you may have the following folders under the software folder:

Approved
Unapproved

In this case, you would create more 'Domain Local' groups for the subfolders as follows:

PROVO-FS1.Software.Approved.Read
PROVO-FS1.Software.Approved.Write
PROVO-FS1.Software.Approved.Modify
PROVO-FS1.Software.Approved.Full

PROVO-FS1.Software.Unapproved.Read
PROVO-FS1.Software.Unapproved.Write
PROVO-FS1.Software.Unapproved.Modify
PROVO-FS1.Software.Unapproved.Full

Then, you would disable inheriting on these folders and assign the groups with the appropriate permissions to the appropriate folders.

For subfolders, you can, if needed, add the subfolder's 'Domain Local' group to an appropriate parent folder 'Domain Local' group. In this example, you could add all of these groups to PROVO-FS1.Software.ListFolder. Now, you are ready to assign roles to the 'Domain Local' groups. You could give many roles access to the PROVO-FS1.Software.Approved.Read, but you may only want to add 'Technical Support Users' to PROVO-FS1.Software.Unapproved.Read.

You should never need to adjust permissions at the resource again (Unless you decide you need to add an additional permission set, then you create the group and add it).

Previous: Restricted Groups
Up Next: Active Directory SQL Server Security

1 comment:

  1. Hi David,

    I'm Sarah, Project Coordinator for ActiveDirSec.com a community based voluntary effort, commissioned by former Microsoft Program Manager for Active Directory security (Founder, Paramount Defenses Inc), that is aimed at helping organizations gain a better understanding of administrative delegation in Active Directory.

    The website currently helps IT admins and IT managers understand how to correctly verify assess, audit and report delegated access in Active Directory. It also provides a helpful reference section.

    In the spirit of collaboration, we're planning on introducing helpful articles and welcome informative contributions from IT admins and architects who have an interest in the field.

    The benefits of contribution include the opportunity to share you experience and knowledge with others, the opportunity to gain recognition within the community, and the opportunity to increase the visibility of your blog / website.

    We came across your blog and thought we'd drop you a note in case you might be interested. You're welcome to visit us online, and should you wish to contribute, please feel free to contact us (details on how to contact us are on the ABOUT page of the website.)

    We wish you all the very best and look forward to hearing from you.

    Kind Regards,
    Sarah

    ReplyDelete