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.
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.
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.
Roles and powers represent subsets of administration authority that you want to grant to AAs.
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.
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 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.
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 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.
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.
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.
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.
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:
Rule for this AA group includes all the employees in the Atlanta Help Desk group.
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:
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.
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.
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.
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.
When the Administration server receives a request for an action, such as changing a user password, it uses the following process:
Search all ActiveViews for the object of this action.
Validate the powers assigned to the account that is requesting the action.
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.
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.
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.
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.
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.
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.
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 |