Learn AD in 15 Minutes a Week: AD Delegation of Authority - Permission Settings and Inheritance

Learn AD in 15 Minutes a Week: AD Delegation of Authority - Permission Settings and Inheritance


August 28, 2002

by Jason Zandriwww.2000trainers.com

Welcome to the 13th installment of Learn Active Directory Design and Administration in 15 Minutes a Week, a weekly series aimed at current IT professionals preparing to write the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft. This installment is going to cover the Windows 2000 Active Directory Delegation of Authority - Permission Settings and Inheritance, with a specific focus on controlling Permission Inheritance to Active Directory objects and setting permissions to Active Directory objects.


Controlling Permission Inheritance

Active Directory object permission inheritance automatically causes objects in a container to inherit the permissions of that container or that of the parent container(s).

Permission inheritance is enabled by default to help minimize administration by limiting the number of times you need to assign specific permissions for all Active Directory objects.

When new Active Directory objects are created, they inherit permissions that exist in the parent container at the time of their creation.

The design of permission inheritance is such that the permissions apply downward in the hierarchy to the objects child objects once they are created. If you create an Organizational Unit named Sales and allow the Saleslead group to have the Full Control permission assigned to the Sales OU, once the three child OUs of Users and Desktops and Laptops are created they will inherit the same permission settings, and the Saleslead group will also have the Full Control permission to those objects as well.

[NOTES FROM THE FIELD] - Domain and Enterprise Administrators have the right to allow or deny permissions for every object in Active Directory, in addition to any other owners that may own the objects.

You can prevent the inheritance of permissions when you need to set a different level of security access to a child container than that of the parent container. Usually this is done when you need more restrictive control over a child container than a parent, but it can also be the case of where the child container needs to have special permissions applied.

In order to block inheritance, you need to remove the checkmark from the "Allow inheritable permissions from parent to propagate to this object" checkbox. You will then be prompted to either Copy the currently inherited permissions locally, so that the object will still have the locally set level of permissions that they had through inheritance, or you can remove all permissions by selecting Remove.  



You would normally copy the settings locally and adjust them to the finer degree that you require, but there are cases where you might remove them all and start from scratch in order to better guarantee that the object is as secure as you require.

[NOTES FROM THE FIELD] - If you remove all permissions and then do not assign any locally, and then close out the dialog box, you will receive a warning that you have denied everyone access to the object and that no one will be able to access it, and only the object owner will be able to change permissions if you select Yes to continue.


Standard Permissions

Once you have copied the permissions locally (or removed them entirely), you can begin to set them locally on the object. In order to set, add or change locally copied permissions to any of the standard permission levels, you need to open the Active Directory Users and Computers MMC and find the object you want to administer. Once you have done this, you need to right click the object to edit its properties. You would go to the security tab and either add or remove users in the upper portion of the security box to allow and/or deny general access to the object.

[NOTES FROM THE FIELD] - When you add a user or group, you are preparing to explicitly set some level of access. When you remove a current user or group or intentionally elect to not add them, you are implicitly denying them access.

When permission to perform an operation is not explicitly assigned, it is implicitly denied. What this means is that if you are not given any permissions to an object, you are denied access to it by the fact that you have no access in the first place.

When permission to perform an operation is implicitly assigned, it can be explicitly denied. What this means is that if permissions are set via inheritance or through group membership, it can be still set to deny at a local object. If a specific user is gaining access to an object through inheritance, you can set a local deny for that user on the object itself. If a specific user is gaining access to an object through group membership and you want that group but not that given user to have access, you can deny the user access locally at the object.

Once you have controlled which users or groups that you want to allow (or deny) access to the object, you can then set permission levels to them in the standard permissions section in the lower part of the security tab.



Full Control allows you to change permissions and take ownership, as well as perform the tasks that are allowed by all other standard permissions.

Read allows for the viewing of objects and object attributes, the object owner, and the Active Directory permissions.

Write allows for the ability to change the attributes of an object.

Create All Child Objects allows for the addition of any type of child object in Active Directory.

Delete All Child Objects allows for the removal of any type of child object in Active Directory.

While it is possible to assign permissions directly to users, best practices dictate that Administrators should only assign permissions to groups for the easiest administration.

 


Special Permissions

You may find a special case in your environment where the standard permission settings do not allow you to set the desired level of security or access required to a given object. Special permissions can be set in cases such as this.

Whenever possible, you should avoid assigning special permissions for specific attributes of objects, as the administration of multiple Active Directory objects in this manner becomes cumbersome.

If you find that there is an absolute business need for setting special permissions, this can be done by first opening the Active Directory Users and Computers MMC and then finding the object you want to administer. Once you have done this, you would need to right click the object to edit its properties. You would go to the security tab and select the Advanced button.



You can then select the required permission entry and click on the View/Edit button to further edit the permission.




Well, that wraps up this section of Learn Active Directory Design and Administration in 15 Minutes a Week, which covered the Windows 2000 Active Directory Delegation of Authority - Permission Settings and Inheritance. I hope you found it informative and will return for the next installment. 

If you have any questions, comments or even constructive criticism, please feel free to drop me a note.

I want to write good, solid technical articles that appeal to a large range of readers and skill levels and I can only be sure of that through your feedback.

Until then, best of luck in your studies and remember,


"I still have yet to figure out why you can tell someone that there are 400 billion stars and they'll believe you, but tell them that a bench has wet paint and they have to touch it."


Jason Zandri
Jason@Zandri.net

www.2000trainers.com