Best practices for assigning permissions on Active Directory objects
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Best practices for assigning permissions on Active Directory objects
For information on security and access control in Active Directory, see Securing Active Directory and Access control in Active Directory.
If possible, avoid changing the default permissions on Active Directory objects
- Changing default permissions could cause unexpected access problems or reduce security.
Avoid granting Full Control permissions over an object or organizational unit
- Granting someone Full Control allows them to take ownership of an object and modify the permissions on it. If someone has Full Control on a container, then they can Take Ownership of, and have Full Control over, all objects in that container. As far as possible, instead of allowing Full Control, give only the permissions needed by the user.
Minimize the number of access control entries that apply to child objects
- When using the Apply Onto option to control inheritance, be aware that not only will the specified objects inherit that access control entry (ACE) but all child objects will also receive a copy of that ACE. If there are enough objects that will get copies of this ACE, then that increased amount of data can cause performance problems on your network.
When possible, assign the same set of permissions to multiple objects
- Access control lists (ACLs) in the Windows Server 2003 family feature single-instancing: If multiple objects have identical access control lists (ACLs), then Active Directory will only store one instance of the ACL. For more information on how inheritance works for Active Directory objects, see Changing inherited permissions.
When possible, assign access rights on a broad level rather than assigning individual user rights
Minimizing the number of access control entries will improve performance.
Allow "Read All Properties" or "Write All Properties" rather than individual properties.
Allow Read or Write access to property sets rather than individual properties.
A property set is a collection of attributes. For example, the Personal Information property set includes the attribute's address, personal title, and so on. By setting access on the property set, you have automatically set access on all the attributes contained in that property set.
Allow "Create All Child Objects" or "Delete All Child Objects," rather than specifying individual child objects.
Allow "All Extended Rights" rather than allowing the individual extended rights.
Allow "All Validated Writes" rather than allowing the individual validated rights.
Note
- There are times when assigning individual permissions is appropriate. For example, if a Help Desk operator needs Write access to two properties of a User object, then it makes sense to use one access control entry (ACE) for each of them, rather than trying use only one ACE by granting write access to the entire user object.
Whenever possible, assign permissions to groups rather than users
Use groups to delegate authority over the directory. If one set of users needs Read permissions, and another set of users needs Change permissions, then create one group for each set of users and assign the permission to the group. If multiple global groups need the same access, create a local group containing the global groups and assign permissions to the local group.
For more information, see Active Directory object permissions.
Caution
- The operation of your domain may become impaired if the total size of all the Active Directory permissions approaches the disk storage or processing speed capacity of your domain controller. Minimize the number of individual permissions that are propagated to child objects.
Notes
Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.