2.1 Understanding the Dynamic Security Model

DRA and ExA allow you to manage your enterprise within the context of a dynamic security model. This model ensures that your enterprise management and security remains current as your enterprise changes and evolves. Dynamic security allows you to control the issues you have today while providing a stable foundation for future solutions.

2.1.1 What Is Distributed Administration?

Distributed administration allows you to delegate specific authority to one or more people. With distributed administration, you can easily and safely grant powers over a set of objects regardless of your domain or organizational unit (OU) structure.

When you use distributed administration, you create rules that define who can do what to whom or what.

who

Assistant Admins (AAs) represent one or more user accounts, groups, or AA groups. AAs manage the user accounts, groups, contacts, OUs, and resources in an ActiveView.

what

Roles and powers represent subsets of administration authority that you want to grant to AAs.

whom or what

ActiveViews represent a set of objects your AAs can manage collectively.

These rules establish and control your security model. When using a dynamic security model, these rules provide the flexibility you need to automatically maintain security while your enterprise changes.

The following figure illustrates this rules based model.

2.1.2 What Is the Dynamic Security Model?

The dynamic security model provides powerful and flexible rules based management for your enterprise. This model enhances distributed administration by accommodating change. Rather than delegating a power to a person, you are delegating roles to people. In this way, the dynamic security model more closely represents how your company works, letting you design your enterprise security to support workflows across organizations. You can expand this flexibility by configuring rules that match established naming conventions or group memberships.

In the dynamic security model, roles can be reused in different ActiveViews and assigned to different AAs, user accounts can be moved from one AA group to another, and powers can be moved from one role to another. As these changes occur, DRA and ExA automatically update security settings across your enterprise.

When you develop your administration and security plan, first identify the workflows your company has. Each workflow determines who can do what to whom or what. Use your workflow definitions to create the appropriate AA groups, assign the required roles, and configure the corresponding ActiveViews.

Roles

Roles are the what in the dynamic security model. A role is a set of powers that provide the permissions required to perform a specific administration task, such as creating a user account or moving shared directories. To create a role, first define the job description. The job description provides the list of powers an Assistant Admin needs to perform a task or complete a workflow.

A role can contain any set of powers you specify. Because you can choose from hundreds of powers, you have the flexibility to create roles that best fit your organization. You can also use the pre-defined built-in roles that are installed with the product. For more information about built-in roles, see Understanding the Default Security Model.

When you add a power to a role, any Assistant Admin associated with that role automatically receives the new power. You can add roles to other roles, creating a hierarchical model based on increasing power. You can also associate the same role to different Assistant Admin groups.

Roles by themselves do not grant power. To delegate power, you must associate the role with an Assistant Admin in an ActiveView.

Powers

A power defines the properties of an object an Assistant Admin can view, modify, or create in your managed domain or subtree. A group of powers forms a role. DRA allows you to group powers into roles and delegate the roles and powers to users, group accounts, and Assistant Admin groups.

The Delegation and Management taskpad allows you to list built-in powers, clone and create new powers, assign powers to ActiveViews and Assistant Admin groups, change properties of custom powers, and view all powers. Roles are created from the inclusion of multiple powers.

ActiveViews

ActiveViews are the whom or what in the dynamic security model. An ActiveView represents a set of objects. When you create or modify an ActiveView, you specify rules that define which objects you want to manage as a collection. The ActiveView rule also associates AAs with roles and powers to manage this collection of objects.

2.1.3 What ActiveViews Provide

ActiveViews allow you to implement a security model that has the following features:

  • Is independent from your Active Directory structure

  • Allows you to assign powers and define policies that correlate to your existing workflows

  • Provides automation to help you further integrate and customize your enterprise

  • Dynamically responds to change

An ActiveView represents a set of objects within one or more managed domains. You can include an object in more than one ActiveView. You can also include many objects from multiple domains or OUs.

ActiveViews Include Dynamic Sets of Objects

An ActiveView provides real time access to specific objects within one or more domains or OUs. You can add or remove objects from an ActiveView without changing the underlying domain or OU structure.

You may think of an ActiveView as a virtual domain or OU, or the results of a select statement or database view for a relational database. ActiveViews can include or exclude any set of objects, contain other ActiveViews, and have overlapping contents. ActiveViews can contain objects from different domains, trees, and forests. You can configure ActiveViews to meet any enterprise management need.

ActiveViews can include the following types of objects:

  • User accounts

  • Direct reports

  • Groups

  • Managed groups

  • Organizational units

  • Contacts

  • Computers

  • Resources, such as:

    • printers

    • print jobs

    • published printers

    • published printer print jobs

    • open files

    • connected users

    • event logs

    • shares

    • devices

    • services

  • Domains

  • Other ActiveViews

  • Resource mailboxes

  • Shared mailboxes

  • Exchange Dynamic Groups

  • Member servers

You specify which objects DRA will include in an ActiveView by querying the object attributes, much as you would make a query to select items from a database. As your enterprise changes or grows, ActiveViews change to include or exclude the new objects. Thus, you can use ActiveViews to reduce the complexity of your model, provide the security you need, and give you far more flexibility than other enterprise organizing tools.

ActiveViews Include Flexible Rules

An ActiveView can consist of rules that include or exclude objects such as user accounts, groups, OUs, contacts, resources, computers, resource mailboxes, shared mailboxes, dynamic distribution groups, and ActiveViews. In addition, ActiveView rules can specify security and policy objects. When you specify a wildcard character in a rule specification, the rule includes all objects that match the specified value. This flexibility makes ActiveViews dynamic.

These matches are called wildcards. When you add a rule to an AA group using wildcards, the rule includes all computer accounts that match the specified pattern. For example, you can define a rule to include all computers with names matching DOM*. This wildcard specification will search for any computer account whose name begins with the character string DOM. Wildcard matching makes administration dynamic because accounts are automatically included when they match the rule. Thus, when you use wildcards, you do not need to reconfigure the ActiveViews as your organization changes.

Another example is defining ActiveViews based on group membership. You can define a rule that includes all members of groups that begin with the letters NYC. Then, as members are added to any group matching this rule, these members are automatically included in this ActiveView. As your enterprise changes or grows, DRA reapplies the rules to include or exclude the new objects in the proper ActiveViews.

2.1.4 ActiveViews and Distributed Administration

ActiveViews help you distribute administration tasks to specific people. For example, to allow members of the Atlanta Help Desk group to reset passwords and unlock accounts for users in Atlanta, an administrator at the Houston headquarters defines the following rules:

Atlanta Help Desk Assistant Admins

Rule for this AA group includes all the employees in the Atlanta Help Desk group.

Atlanta User Accounts ActiveView

Rules for this ActiveView include all the user accounts in Atlanta and associate the Reset User Passwords role with the Atlanta Help Desk AAs. By distributing administration through the Atlanta User Accounts ActiveView, the Houston administrator achieves the following benefits:

Improved service to users in Atlanta

Users in Atlanta no longer need to call Houston if they forget their password. Any time a new user account is added in Atlanta, the user account is included automatically in the Atlanta User Accounts ActiveView. Atlanta Help Desk Assistant Admins can now reset passwords for this new user account.

Reduced workload for the central administrators in Houston

Atlanta Help Desk Assistant Admins can reset passwords for users in the Atlanta User Accounts ActiveView while the Houston administrators focus their attention on other issues.

Enhanced security for the corporation

Atlanta Help Desk Assistant Admins are in a better position to determine whether a request to reset a password from a user in Atlanta is valid. Therefore, distributing this portion of the administration workload permits the corporation to run with fewer Microsoft Windows administrators, maintaining a higher level of security.

Reset User Passwords Role

Rules for this role include all the powers needed to unlock user accounts and reset passwords.

In this way, DRA allows you to manage your organization the way you think and work. Once you establish your own security model using ActiveViews, the model can grow and change as your organization does. For more information about implementing help desk administration, see the Product Overview Guide.

2.1.5 How the Administration Server Processes Requests

When the Administration server receives a request for an action, such as changing a user password, it uses the following process:

  1. Search all ActiveViews for the object of this action.

  2. Validate the powers assigned to the account that is requesting the action.

  3. If the account has the correct power, the Administration server allows the action to be performed.

    If the account does not have the correct power, the Administration server returns an error.

  4. Update the Active Directory.

For example, when you attempt 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 you have the Reset User Account Password power in any of these ActiveViews. If you have the Reset User Account Password power, the Administration server resets the password for JSmith. If you do not have this power, the Administration server denies your request.

2.1.6 How Powers Can Increase

A power defines the properties of an object an Assistant Admin 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.

2.1.7 Understanding How Powers Increase

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 security 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 AAs to manage the same objects differently.

Using Powers in Multiple ActiveViews

Assume there is an AA, 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.

Extending Powers

You can add permissions or functionality to a power by extending that power.

For example, to allow an AA to create a user account, you can assign either the Create User and Modify All Properties power or the Create User and Modify Limited Properties power. If you also assign the Add New User to Group power, the AA can add this new user account to a group while using the Create User wizard. In this case, the Add New User to Group power provides an additional wizard feature. The Add New User to Group power is the extension power.

Extension powers cannot add permissions or functionality by themselves. To successfully delegate a task that includes an extension power, you must assign the extension power along with the power you want to extend.

NOTE:

  • To successfully create a group and include the new group in an ActiveView, you must have the Add New Group to ActiveView power in the specified ActiveView. The specified ActiveView must also include the OU or built-in container that will contain the new group.

  • To successfully clone a group and include the new group in an ActiveView, you must have the Add Cloned Group to ActiveView power in the specified ActiveView. The specified ActiveView must also include the source group as well as the OU or built-in container that will contain the new group.

The following table lists the administration tasks that include extension powers.

To Delegate This Task

Assign This Power

And This Extension Power

Clone a group and include the new group in a specified ActiveView

Clone Group and Modify All Properties

Add Cloned Group to ActiveView

Create a group and include the new group in a specified ActiveView

Create Group and Modify All Properties

Add New Group to ActiveView

Create a mail enabled contact

Create Contact and Modify All Properties

Create Contact and Modify Limited Properties

Enable Email for New Contact

Create a mail enabled group

Create Group and Modify All Properties

Enable Email for New Group

Create a mail enabled user account

Create User and Modify All Properties

Create User and Modify Limited Properties

Enable Email for New User

Create a user account and add the new account to specific groups

Create User and Modify All Properties

Create User and Modify Limited Properties

Add New User to Group