8.3 Examples of How DRA Processes Delegation Assignments

When an assistant administrator attempts to set a new password for the JSmith user account, the Administration server finds all ActiveViews that include JSmith. This search looks for any ActiveView that specifies JSmith directly, through a wildcard rule, or through group membership. If an ActiveView includes other ActiveViews, the Administration server also searches these additional ActiveViews. The Administration server determines whether the assistant administrator has the Reset User Account Password power in any of these ActiveViews. If the assistant administrator has the Reset User Account Password power, the Administration server resets the password for JSmith. If he does not have this power, the Administration server denies the request.

A power defines the properties of an object an assistant administrator can view, modify, or create in your managed domain or subtree. More than one ActiveView can include the same object. This configuration is called overlapping ActiveViews.

When ActiveViews overlap, you can accumulate a set of different powers over the same objects. For example, if one ActiveView allows you to add a user account to a domain and another ActiveView allows you to delete a user account from the same domain, you can add or delete user accounts in that domain. In this way, the powers you have over a given object are cumulative.

It is important to understand how ActiveViews can overlap and you can have increased powers over objects included in these ActiveViews. Consider the ActiveView configuration illustrated in the following figure.

The white tabs identify ActiveViews by location, New York City and Houston. The black tabs identify ActiveViews by their organizational function, Sales and Marketing. The cells show the groups included in each ActiveView.

The NYC_Sales group and the HOU_Sales group are both represented in the Sales ActiveView. If you have power in the Sales ActiveView, then you can manage any member of the NYC_Sales and HOU_Sales groups. If you also have power in the New York City ActiveView, then these additional powers apply to the NYC_Marketing group. In this way, powers accumulate as the ActiveViews overlap.

Overlapping ActiveViews can provide a powerful, flexible delegation model. However, this feature can also have unintended consequences. Carefully plan your ActiveViews to ensure each AA has only the powers you intend over each user account, group, OU, contact, or resource.

Groups in Multiple ActiveViews

In this example, the NYC_Sales group is represented in more than one ActiveView. The members of the NYC_Sales group are represented in the New York City ActiveView because the group name matches the NYC_* ActiveView rule. The group is also in the Sales ActiveView because the group name matches the *_Sales ActiveView rule. By including the same group in multiple ActiveViews, you can allow different assistant administrators to manage the same objects differently.

Using Powers in Multiple ActiveViews

Assume there is an assistant administrator, JSmith, who has the Modify General User Properties power in the New York City ActiveView. This first power allows JSmith to edit all the properties on the General tab of a user properties window. JSmith has the Modify User Profile Properties power in the Sales ActiveView. This second power allows JSmith to edit all the properties on the Profile tab of a user properties window.

The following figure indicates the powers JSmith has for each group.

JSmith has the following powers:

• General Properties in the NYC_* ActiveView

• Profile Properties in the *_Sales ActiveView

The power delegation in these overlapping ActiveViews allows JSmith to modify the General and Profile properties of the NYC_Sales group. Thus, JSmith has all the powers granted in all the ActiveViews that represent the NYC_Sales group.