2.3 Implementing Your Dynamic Security Model

By designing and implementing an environment that is both secure and easy to manage, you can maximize the power and flexibility DRA and ExA offer. Through a dynamic security model, you can distribute and automate many administration tasks and duties.

This section describes key concepts about dynamic, distributed administration and illustrates these concepts with examples and scenarios. These examples and scenarios assume you have the DRA Administration role or the corresponding powers. Review these sections to learn about the following concepts:

  • How to implement your security model with DRA and ExA

  • How to build dynamic, self maintaining ActiveViews

  • How to harness the power of overlapping and hierarchical ActiveViews

DRA and ExA provide powerful tools for distributing specific administration permissions. In addition, these products provide policy and automation features to help you streamline your security model.

2.3.1 How to Create a Security Model

When you design and implement your security model, consider the following questions:

  • Which objects need to be managed?

  • Which actions need to be performed to complete a specific task?

  • Which people need to perform these tasks and manage these objects?

How you answer these questions determines what types of ActiveViews, roles, and AA groups you need. Your answers also determine what type of security model you should create.

NOTE:If you are managing a subtree of a domain, you can implement the DRA security model on the Administration server in the corresponding domain or in another domain managed by DRA.

For more information about these security model components, see Understanding the Dynamic Security Model and Understanding the Default Security Model.

Delegating Administration through a Static Model

When you distribute administration through a static security model, you define rules that include specific objects, delegate specific powers, and assign specific AAs to manage these objects. You define a unique rule for each object, power, and AA.

A static model can be appropriate for situations in which the enterprise scope is unlikely to change. However, this approach has limitations. It can prevent your security model from automatically responding to change, and it can require more maintenance.

For example, suppose JSmith, the Executive Assistant for Engineering, needs to change the home addresses and phone numbers for the five engineering managers. You can create an ActiveView that includes these five user accounts by defining a rule for each account. You can assign the individual powers to JSmith. However, when the Executive Assistant for Marketing needs to change personal information for the marketing managers, you must duplicate your original efforts. If you need to limit powers later, you must manually remove the unwanted powers from each ActiveView in which the Executive Assistants have power.

Delegating Administration through a Dynamic Model

When you distribute administration through a dynamic security model, you define rules that include multiple objects, delegate reusable sets of powers, and assign multiple AAs to manage these objects. You define rules that specify these objects, powers, and AAs through naming conventions, wildcard matching, group memberships, and roles. In this way, a dynamic model allows you to more effectively respond to change and decrease maintenance.

Using groups can help simplify your security model while providing a more dynamic solution. Instead of assigning individual powers to individual user accounts, you assign roles to a group. Each group member inherits the powers assigned to the group. In this model, when you add a user account to the group, the user automatically gains the set of powers associated with this group. When you add a power to the role, each group member automatically gains that power. You do not need to redefine your security model to accommodate a changing enterprise environment.

For example, suppose JSmith, the Executive Assistant for Engineering, needs to change the home addresses and phone numbers for all engineering managers.

You can create the following objects:

  • A group called Engineering Managers

  • A group called Executive Assistants With Power

  • A role called Modifying Home Information

You can assign the Modifying Home Information role to the Execute Assistants With Power group, delegating the same set of powers to all members of that group. You can also create an ActiveView that includes user accounts from the Engineering Managers group. Thus, when a new manager is hired, you can immediately allow JSmith to access the account properties by adding this new user to the Engineering Managers group. This dynamic delegation occurs because the ActiveView rule uses group membership to automatically include the new account.

Understanding Power Creation

A power defines the properties of an object an Assistant Admin can view, modify, or create in your managed domain or subtree. You can create custom powers. Custom powers allow you to delegate power over specific object properties.

You can create custom powers for many different scenarios. You can create or clone specific powers you need to include in roles for common administration tasks. For example, you may need a power to control some properties that have been added to your schema or to grant power over an Active Directory property that is exposed in the DRA consoles with a UI extension. Custom powers can include access to multiple powers, such as the View All User Properties power, so a custom power should contain all the necessary properties to control the object you want to manage or modify. To create a power, you must have the appropriate powers, such as those included in the Manage Security Model role. For more information about custom powers, see Section C.0, Custom Powers.

Understanding Role Creation

A role should contain all the necessary powers to complete a particular job or workflow. In this way, a role presents a job description. You can create new roles that group together specific powers you need or use the provided built-in roles for common administration tasks. For example, you may need a role that includes the powers to only reset passwords of user accounts.

When implementing roles in a dynamic security model, you can take advantage of this flexibility by assigning roles to AA groups. This delegation helps your model ensure that the proper people have the required permissions.

For more information about built-in roles, see Understanding Built-in Roles.

Understanding Assistant Admin Group Creation

An AA group contains all the user accounts and groups you want to grant powers. AA groups typically have roles within your security model. When you create AA groups, you can include user accounts, groups, and other AA groups. You can specify accounts and groups by name or use a wildcard specification that matches multiple accounts and groups.

If you create a static AA group that includes specific user accounts, you must maintain the group definition each time you want to add or remove someone from that AA group. For example, each time you add a user to a static AA group, you must define a rule that specifies the user account.

An easier way to implement your model is to create dynamic AA groups based on naming conventions or group memberships. Dynamic AA groups reduce and simplify your enterprise maintenance.

For example, wildcard specifications allow you to define dynamic AA groups that include user accounts and groups based on criteria, such as naming conventions. These definitions are self maintained. When you define AA group membership through a wildcard specification, DRA automatically updates the AA group membership whenever a new account matches the wildcard specification.

Another way to incorporate flexibility into your model is to define groups based on group membership. For example, you could create an AA group that includes all Help Desk personnel in the New York City office. If you have a group, such as NYC_HelpDesk, that includes these user accounts, you can include that group in an AA group. Then, when you update the membership of the NYC_HelpDesk group, DRA automatically updates the AA group membership.

NOTE:To fully grant powers to an AA group, you must create an ActiveView and associate the AA group with a role in that ActiveView.

Understanding ActiveView Creation

ActiveViews provide access to defined sets of objects, such as contacts or print jobs. When you create an ActiveView, you are creating an ActiveView object that has basic properties, such as a name and a description. To use this ActiveView, you must add objects, assign AAs, and assign roles or powers. The result is an ActiveView containing objects that particular AAs can view and manage.

For example, you can create a NYC_Sales People ActiveView that represents a set of user accounts, such as all the user accounts in the NYC_Sales group. Then, you can assign the NYC Help Desk AA group to the Update User Addresses role and the NYC_Sales People ActiveView. Through this delegation, you are giving the NYC_HelpDesk group members the ability to modify the address fields of all user accounts in the NYC_Sales group.

DRA provides a Delegation Wizard that allows you to easily and quickly define and assign ActiveViews. For more information, see the Getting Started Guide.

You also can use ActiveView rule restrictions to limit how an AA manages a set of objects. When defining which objects an ActiveView will include, you can select a restriction that designates these objects as source objects or target objects. For example, when the AA adds a user account to a group, the user account is the source object and the group is the target object. If you select the Do not allow the users to be added to groups or moved to OUs restriction, the AA cannot manage these user accounts as source objects. If you select this restriction, DRA will not allow the AA to add a user account in this ActiveView to any group in the enterprise.

Optimizing Your ActiveView Rules

You can configure your ActiveView rules to optimize performance for your enterprise. The following optimization tips can significantly increase performance when managing domains that contain over 250,000 objects.

Specific Matches

Specific matches let you identify the exact objects to include in an ActiveView. For example, you can create an ActiveView that includes user accounts from a specific OU. If your Active Directory structure allows you to specify objects by OU or domain, define rules that include objects from the specific OU or domain. If you need to specify objects from several OUs, and these OUs are unlikely to change, define a rule for each OU. For example, if you want to create an ActiveView that includes computers from the Sales and Marketing OUs, define a rule for each OU.

All rules that define a specific object, such as an OU, group, user, computer, resource type, contact, or domain, can optimize your model. You can also optimize a wildcard rule, such as including all user accounts whose description matches Sales, by specifying the domain of these accounts. Rules that specify a user principal name or logon name may not optimize your model.

Wildcards

If your security model uses a naming convention, wildcards offer tremendous power and flexibility. For example, you can create an ActiveView that includes computers whose pre-Windows 2000 names match ATL*. When using a naming convention, keep in mind that wildcard matches that look for prefixes (ATL*), groups, or pre-Windows 2000 names provide better performance.

You can use wildcards instead of regular expressions to narrow or broaden the scope of the rule. Wildcard matching is not case‑sensitive. You can also use the question mark (?), asterisk (*), or number sign (#) wildcard characters as normal characters by prefixing a backslash (\) to the particular wildcard character. For example, to search for abc*, type the search text abc\*.

DRA and ExA support the following wildcard characters. You cannot use wildcard characters in names.

Match Item

Character

Definition

Any character

Question mark   ?

Matches exactly one character

Any digit

Number sign      #

Matches one digit

Any character, 0 or more matches

Asterisk            *

Matches zero or more characters

The following table provides examples of wildcard character specifications and what they match and do not match.

Example

Matches

Does Not Match

Den???

Denton and Dennis

Denison

El ????o

El Campo and El Indio

El Paso

Houston, TX #####

Houston, TX 77024

Houston, TX USOFA

DRA and ExA do not support wildcard specifications that contain logical operations.

Groups

Groups can help you implement a dynamic security model while optimizing performance. For example, if you need to configure an ActiveView that includes many objects from multiple OUs or domains, you can create a group that contains these objects and then create an ActiveView that includes members of this group. In this case, the ActiveView has one rule that acts on one specific object (the group), even though it includes multiple objects (the group members).

If the Active Directory structure and group set are unlikely to change, you can define a rule for each group, specifying the group and its members.

To make your security model dynamic, the ActiveView can be maintained through a wildcard specification that acts on established group naming conventions. For example, if the pre-Windows 2000 names of your groups have a common prefix, you can define a single rule that matches this prefix.

2.3.2 Delegation Management Node

Use the Delegation Management node to define and maintain your security model. Delegation Management consists of the following nodes:

ActiveViews

Allows you to list current ActiveViews, create and clone ActiveViews, delegate administration, define ActiveView rules, and view managed objects. You can also view assigned AA groups and roles.

Roles

Allows you to list current roles, create roles, delegate administration, add powers to roles, nest roles within a role, clone individual roles or nested roles, delete roles, and view the properties of a role. You can also view assigned AA groups and ActiveViews.

Powers

Allows you to list built-in and custom powers, create and clone powers, and view and change power properties. Directory and Resource Administrator offers you the ability to quickly and efficiently manage and create custom powers. New powers allow you to delegate power over specific object properties. A power defines the properties of an object an Assistant Admin can view, modify, or create in your managed domain or subtree. Custom powers can include access to multiple properties, such as the View All User Properties power.

Assistant Admins

Allows you to list current AAs and AA groups, create and clone AA groups, delegate administration, define AA group rules, and view AA properties. You can also view AA group members and assigned roles and ActiveViews.

Allowing Users to Change Personal Information

You can allow users to manage personal information for their own accounts. This type of administration is called self administration. AAs with self administration permissions can change their basic account properties, such as telephone numbers and street addresses.

To delegate self administration:

  1. In the left pane, select Delegation Management.

  2. Under Common Tasks in the right pane, click Delegate Administration.

  3. On the Welcome window, click Next.

  4. Add the user accounts or groups to whom you want to delegate self-administration, and then click Next.

  5. Add the Self Administration role, and then click Next.

    For more information, see Understanding Built-in Roles.

  6. On the Add menu, click Objects that match a rule.

  7. Click Self Administration, and then click OK. This rule automatically includes the AAs you assigned.

  8. Click Next.

  9. Specify the name, description, and comment for this new ActiveView.

  10. Click Finish.