You learned how to create
users, groups, computers, and OUs and how to access the properties of
those objects. Your ability to perform those actions was dependent on
your membership in the Administrators group of the domain. You would not
want every user on your help desk team to be a member of the domain’s
Administrators group just to reset user passwords and unlock user
accounts. Instead, you should enable the help desk and each role in your
organization to perform the tasks that are required of the role and no
more. In this lesson, you learn how to delegate specific administrative
tasks within Active Directory. This is achieved by changing the
access control lists (ACLs) on Active Directory
objects.
In most organizations, there is more than one administrator, and
as organizations grow, administrative tasks are often distributed to
various administrators or support organizations. For example, in many
organizations, the help desk can reset user passwords and unlock the
accounts of users who are locked out. This capability of the help desk
is a delegated administrative task.
The help desk cannot usually create new user accounts, but it
can make specific changes to existing user accounts. The capability
that is delegated is specific, or granular.
Continuing the example, in most organizations, the help desk’s
ability to reset passwords would apply to normal user accounts, but
not to accounts used for administration or to service accounts. The
delegation is thus said to be scoped to standard
user accounts.
All Active Directory objects, such as the users, computers, and
groups that you created in the previous lesson, can be secured by
using a list of permissions. So you could give your help desk
permission to reset passwords on user objects. The permissions on an
object are called access control entries (ACEs),
and they are assigned to users, groups, or computers (called
security principals). ACEs are saved in the
object’s discretionary access control list (DACL). The DACL is a part of the
object’s ACL, which also contains the system access control list (SACL) that includes auditing
settings. This may sound familiar to you if you have studied the
permissions on files and folders—the terms and concepts are
identical.
The delegation of administrative control, also called the
delegation of control, or just delegation, simply means assigning permissions that
manage access to objects and properties in Active Directory. Just as
you can give a group the ability to change files in a folder, you can
give a group the ability to reset passwords on user objects.
Viewing the ACL of an Active Directory Object
At the lowest level is the ACL on an individual user object in
Active Directory.
To view the ACL on an object:
-
Open the Active Directory Users And Computers
snap-in.
-
On the View menu, select the Advanced Features
option.
-
Right-click an object and choose Properties.
-
Click the Security tab.
If Advanced Features is not enabled, you will not see the
Security tab in an object’s Properties dialog box.
The Security tab of the object’s Properties dialog box is
shown in Figure 1.
-
Click Advanced.
The Security tab shows a very high-level overview of the
security principals that have been given permissions to the
object, but in the case of Active Directory ACLs, the Security tab is rarely detailed enough to
provide the information you need to interpret or manage the ACL.
You should always click Advanced to open the Advanced Security Settings dialog box.
The Advanced Security Settings dialog box appears, shown in
Figure 2.
The Permissions page of the Advanced Security Settings
dialog box shows the DACL of the object. You can see in Figure 2 that ACEs
are summarized on a line of the Permission Entries list. In this
dialog box, you are not seeing the granular ACEs of the DACL. For
example, the permission entry that is selected in Figure 2 is actually
comprised of two ACEs.
-
To see the granular ACEs of a permission entry, select the
entry and click Edit.
The Permission Entry dialog box appears, detailing the
specific ACEs that make up the entry, as shown in Figure 3.
Property Permissions, Control Access Rights, and Object
Permissions
The DACL of an object allows you to assign permissions to
specific properties of an object. As you saw in Figure 3, you can allow (or deny)
permission to change phone and email options. This is, in fact, not
just one property, but a property set that includes multiple specific
properties. Property sets make it easier to manage permissions to
commonly used collections of properties. But you could get even more
granular and allow or deny permission to change just the mobile
telephone number or just the home street address.
Permissions can also be assigned to manage control access
rights, which are actions such as changing or resetting a password.
The difference between those two control access rights is important to
understand. If you have the right to change a
password, you must know and enter the current password before making
the change. If you have the right to reset a
password, you are not required to know the previous password.
Finally, permissions can be assigned to objects. For example,
the ability to change permissions on an object is controlled by the
Allow::Modify Permissions ACE. Object permissions also control whether
you are able to create child objects. For example, you might give your
desktop support team permissions to create computer objects in the
Client Computers OU. The Allow::Create Computer Objects ACE would be
assigned to the desktop support team at the Client Computers
OU.
The type and scope of permissions are managed using the Object
tab and Properties tab, and the Apply To drop-down lists on each
tab.
