Administering Active Directory Domain Services : Delegation and Security of Active Directory Objects (part 2)

You can imagine that giving the help desk permission to reset passwords for each individual user object would be a nightmare. Luckily, you don’t have to, and, in fact, it’s a terrible practice to give permissions to individual objects in Active Directory. Instead, you give permissions to organizational units. The permissions you give to an OU are inherited by all objects in the OU. So, if you give the help desk permission to reset passwords for user objects, and you attach that permission to the OU that contains your users, all user objects within that OU inherit that permission. With one step, you delegate that administrative task.

Inheritance is an easy concept to understand. Child objects inherit the permissions of the parent container or OU. That container or OU in turn inherits its permissions from its parent container, OU, or, if it is a first-level container or OU, from the domain itself. The reason child objects inherit permissions from their parents is that, by default, each new object is created with the Include Inheritable Permissions From This Object’s Parent option enabled. You can see the option in Figure 2.

However, note that as the option indicates, only inheritable permissions are inherited by the child object. Not every permission is inheritable. For example, the permission to reset passwords, when assigned to an OU, would not be inherited by group objects because group objects do not have a password attribute. So inheritance can be scoped to specific object classes; passwords are applicable to user objects, not to groups. Additionally, you can use the Apply To box of the Permission Entry dialog box to scope the inheritance of a permission. The conversation can start to get very complicated. What you should know is that, by default, new objects inherit inheritable permissions from their parent object—usually an OU or container.

What if the permission that is being inherited is not appropriate? You can do three things to modify the permissions that a child object is inheriting.

First, you can disable inheritance by clearing the Include Inheritable Permissions From This Object’s Parent option in the Advanced Security Settings dialog box. When you do, the object no longer inherits any permissions from its parent—all permissions are explicitly defined for the child object. This is generally not a good practice, as it creates an exception to all the rules that are being created by permissions of parent containers.

The second option is to allow inheritance but override the inherited permission with a permission assigned specifically to the child object—an explicit permission. Explicit permissions always override permissions that are inherited from parent objects. This has an important implication: an explicit permission that allows access will actually override an inherited permission that denies the same access. If that sounds counterintuitive to you, it is not: the rule (Deny) is being defined by a parent, but the child object has been configured to be an exception (Allow).

Third, you can change the scope of inheritance on the parent permission itself by changing the option in the Apply To drop-down list in the Permission Entry dialog box. In most cases, this is the best practice. What you are doing, in effect, is defining the security policy in the form of the ACL more accurately at its source, rather than trying to override it further down the tree.

You’ve seen the complexity of the DACL, and you’ve probably gleaned that managing permissions by using the Permission Entry dialog box is not a simple task. Luckily, the best practice is not to manage permissions by using the security interfaces but, rather, to use the Delegation Of Control Wizard. The following procedure explains the use of the wizard.

You can view and report permissions several ways when you need to know who can do what. You’ve already seen that you can view permissions on the DACL by using the Advanced Security Settings and Permission Entry dialog boxes.

DSACLs (Dsacls.exe) is also available as a command-line tool that reports on directory service objects. If you type the command followed by the distinguished name of an object, you see a report of the object’s permissions. For example, this command produces a report of the permissions associated with the User Accounts OU:

dsacls.exe"ou=User Accounts,dc=contoso,dc=com"

DSACLs can also be used to set permissions—to delegate. Type dsacls.exe /? for help regarding the syntax and usage of DSACLs.

How do you remove or reset permissions that have been delegated? Unfortunately, there is no “undelegate” command. You must do one of the following:

Effective permissions are the resulting permissions for a security principal, such as a user or group, based on the cumulative effect of each inherited and explicit ACE. Your ability to reset a user’s password, for example, may be a result of your membership in a group that was given Reset Password permission on an OU several levels above the user object. The inherited permission assigned to a group to which you belong resulted in an effective permission of Allow::Reset Password. Your effective permissions can be complicated when you consider Allow and Deny permissions, explicit and inherited ACEs, and the fact that you may belong to multiple groups, each of which may be assigned different permissions.

Permissions, whether assigned to your user account or to a group to which you belong, are equivalent. In the end, an ACE applies to you, the user. The best practice is to manage permissions by assigning them to groups, but it is also possible to assign ACEs to individual users or computers. A permission that has been assigned directly to you is neither more important nor less important than a permission assigned to a group to which you belong.

Permissions that allow access (Allow permissions) are cumulative. When you belong to several groups, and those groups have been granted permissions that allow a variety of tasks, you can perform all of the tasks assigned to all of those groups as well as tasks assigned directly to your user account.

Permissions that deny access (Deny permissions) override equivalent Allow permissions. If you are in one group that has been allowed the permission to reset passwords, and another group that has been denied permission to reset passwords, the Deny permission prevents you from resetting passwords.

Each permission is granular. For example, if you have been denied the ability to reset passwords, you might still have the ability, through other Allow permissions, to change the user’s logon name or email address.

Finally, you learned earlier in this lesson that child objects inherit the inheritable permissions of parent objects by default, and that explicit permissions can override inheritable Permissions. This means that an explicit Allow permission actually overrides an inherited deny permission.

Unfortunately, the complex interaction of user, group, explicit, inherited, Allow, and Deny permissions can make evaluating effective permissions a bit of a chore. There is an Effective Permissions tab in the Advanced Security Settings dialog box of an Active Directory object, but the tab is practically useless: It does not expose enough permissions to provide the kind of detailed information you require. You can use the permissions reported by the DSACLs command or those reported on the Permissions tab of the Advanced Security Settings dialog box to begin evaluating effective permissions, but it will be a manual task.

OUs are, as you now know, administrative containers. They contain objects that share similar requirements for administration, configuration, and visibility. You now understand the first of those requirements: administration. Objects that will be administered the same way, by the same administrators, should be contained within a single OU. By placing your users in a single OU, perhaps called User Accounts, you could delegate the help desk permission to change all users’ passwords by assigning one permission to one OU. Any other permissions that affect what an administrator can do to a user object would be assigned at the User Accounts OU. For example, you might allow your Human Resources managers to disable user accounts in the event of an employee’s termination. You would delegate that permission, again, to the User Accounts OU.

Remember that administrators should be logging on to their systems with user credentials and launching administrative tools with the credentials of a secondary account that has appropriate permissions to perform administrative tasks. Those secondary accounts are the administrative accounts of the enterprise. It is not appropriate for the front-line help desk to be able to reset passwords on such privileged accounts, and you probably would not want human resources managers to disable administrative accounts. Therefore, administrative accounts should be administered differently than “normal” (non-administrative) user accounts. That’s why you would have a separate OU, such as Admins, for administrative user objects. That OU would be delegated quite differently than the User Accounts OU.

Similarly, you might delegate to the desktop support team the ability to add computer objects to an OU called Client Computers, which contains your desktops and laptops, but not to the Servers OU, where only your Server Administration group has permissions to create and manage computer objects.

The primary role of OUs is to efficiently scope delegation—to apply permissions to objects and sub-OUs. When you design an Active Directory environment, you always begin by designing an OU structure that will make delegation efficient—a structure that reflects the administrative model of your organization. Rarely does object administration in Active Directory look like your organizational chart. Typically, all normal user accounts are supported the same way, by the same team—so user objects are often found in a single OU or a single OU branch. Quite often an organization that has a centralized help desk function to support users also has a centralized desktop support function, in which case all client computer objects are within a single OU or single OU branch. But if desktop support is decentralized, it would be likely that the Client Computers OU would be divided into sub-OUs representing geographic locations, where each location was delegated to allow the local support team to add computer objects to the domain in that location.

Design OUs first to enable the efficient permissioning (delegation) of objects in the directory. After you have achieved that design, you can refine the design to facilitate the configuration of computers and users through Group Policy. Active Directory design is an art and a science.