Step 4: Applying the Access Template
To apply the Sales Access Template to the Sales Managed Unit, right-click the Sales Managed Unit and click Delegate Control. Then, click the Add button and follow the instructions in the Delegation of Control wizard.
On the Users or Groups page of the wizard, add the user or group to be designated as a Trustee.
On the Access Templates page of the wizard, select the Sales Access Template you prepared in Step 3.
For more information on how to apply an Access Template to a Managed Unit, see Applying Access Templates later in this document.
Deployment considerations
Managed Units can best be described as virtual Organizational Units, allowing you to take advantage of delegation and policy application within a logical grouping of objects that may not always correspond with your Active Directory structure. At their rawest form, Managed Units are nothing more than LDAP queries stored in Active Roles’ configuration database. As such, Managed Units can only be configured and accessed via Active Roles’ interfaces. This section covers the following topics, to help you make the best use of Managed Units:
Managed Unit membership rules
It is membership rules that determine the list of objects to be included in a Managed Unit. Although several types of membership rule are available, there are two that are most commonly used. These are query-based inclusion or exclusion rules and explicit inclusion or exclusion rules.
Typically you would use query-based rules to include objects that span multiple Organizational Units or Organizational Unit structures. An example is a Managed Unit that includes all disabled user accounts or a Managed Unit that includes all user accounts without mailboxes. Query-based rules are also used to build logical structures from a flat Organizational Unit structure.
You have to be careful with query-based rules because in essence these are conditions imposed on object attributes. If the value of an object’s attribute does not meet the specified conditions, the object is not included in the Managed Unit. The opposite is also true. If you, for example, configure a Managed Unit to include all users whose name begins with letter A, the Managed Unit would include the Administrator account. If the Helpdesk were delegated control over that Managed Unit, Helpdesk operators could gain control over the Administrator account. This brings in the use for explicit rules.
Explicit rules allow you to include or exclude objects based upon their identifier (GUID). So no matter how the object is changed or renamed, as long as that object exists in the directory, the rule will be in effect. Explicit rules normally complement query-based rules to include an object the query does not cover or to exclude an object that may meet the conditions of the query. Other uses are to statically include an object so no matter what that object is named it will always be included. Most typically this is Organizational Units. You can build a logical structure of Organizational Units from any part of the directory tree by explicitly adding them to a Managed Unit. This makes delegation and policy application much easier, since either can be done at the Managed Unit level instead of each individual Organizational Unit.
The following table lists some useful examples of membership rules. These examples demonstrate how to control membership rules by using LDAP filters. You can apply an LDAP filter under the Custom Search option in either of the query-based rule types.
Table 8: Managed Unit membership rules
|
Groups hidden from the Exchange Address List |
(&(objectCategory=group)(mailnickName=*)(msExchHideFromAddressLists=True)) |
|
Mail-enabled groups |
(&(objectCategory=group)(mailNickName=*)) |
|
Mail-enabled users with forwarders set |
(&(sAMAccountType=805306368)(mailNickName=*)(altRecipient=*)) |
|
Users who do not have an Exchange mailbox |
(&(sAMAccountType=805306368)(!(homeMDB=*))) |
|
Distribution groups |
(&(objectCategory=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648))) |
|
Security groups |
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)) |
|
Disabled user accounts |
(&(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=2)) |
|
Users from the Sales department |
(&(objectCategory=user)(department=Sales)) |
Delegation of Managed Units
You can delegate Managed Units exactly like Organizational Units or an entire domain, by applying Access Templates in Active Roles. This can drastically expedite deployment, ease administrative burden for Active Roles itself, and simplify the training and job processes for the administrators using this tool.
For instance, by grouping all disabled and locked out accounts within a single Managed Unit, you can delegate control to a Helpdesk group so that they can quickly and easily perform a large part of their job function by only having to enumerate and look through a single structure. Also, when delegating control of a Managed Unit, you do not have to give your delegated administrators access to any Organizational Unit itself; all objects that meet the membership rules are in the Managed Unit regardless of what Organizational Units hold those objects.
One more example would be where Active Directory has a very flat structure of Organizational Units, however different administrators are responsible for different locations. As long as the location code is stored in an attribute of the objects to be managed, you can create Managed Units based on that attribute, and delegate to each set of administrators a Managed Unit containing their respective objects that meet a particular location code. Since Managed Units are merely groupings of objects based on certain attributes, the objects will move in and out of Managed Units regardless of how their attributes change, either through Active Roles interfaces or natively.
An important feature of Managed Units is the fact that a single Managed Unit can include objects from any domains managed by Active Roles (managed domains). As long as a given domain is registered with Active Roles, regardless of the domain’s forest, any object from that domain can be added to a Managed Unit. When doing delegation of a Managed Unit that holds objects from different domains, it is advisable to use domain local groups from the domain where the Active Roles installation exists, or universal groups. This is because Active Roles allows you to do delegation to any security group within the managed domains; however, if the Active Roles installation exists in domain A and a delegation was done to a domain local group in domain B, an administrator who authenticates against Active Roles in domain A will never have the local group from domain B added to his security token, therefore he will not have his delegated rights. Also global groups can be used as long as all administrative users reside in the domain where Active Roles is installed.
One precaution that must be considered with delegating control of Managed Units is the ability to sync the delegated permissions to Active Directory. When you apply an Access Template to a Managed Unit and do not sync the permissions with Active Directory, the permission settings are only stored within Active Roles’ configuration database. Active Roles maintains the parent-child relationship for the objects held in the Managed Unit, thus allowing permission inheritance to work. If you choose to sync the permissions with Active Directory, there is no way to maintain that parent-child relationship in Active Directory since a Managed Unit is not truly an object within Active Directory so to Active Directory that parent does not exist. As a result, every permission entry found in the Access Template will be included into the native Access Control List of every object held in the Managed Unit. Potentially this could cause performance issues.
