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."

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.