Managed Units (MUs) are virtual Organizational Units (OUs), allowing you to group directory objects and configure delegation and policy settings for them by a logic that may not correspond to your Active Directory (AD) or Azure Active Directory (Azure AD) structure. However, technically, they are LDAP queries stored in the Active Roles Configuration Database. As such, MUs can only be configured and accessed via Active Roles interfaces.
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 had 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.
|
Managed Unit Contents |
LDAP Filter |
|
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)) |
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, and simplify the training and job processes for the administrators using this tool.
For example, 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: 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 recommended 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 you must consider with delegating control of Managed Units is the ability to synchronize 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.
Active Roles provides safe, distributed administration through advanced delegation of rights with high granularity to individual users or groups. This relieves highly skilled administrators from routine day-to-day tasks, saving time and increasing productivity. For example, an administrator can allow helpdesk to perform specific tasks, such as resetting passwords or managing group memberships, without granting full administrative privileges.
As you develop your administration and security design, you define delegated administrators (Trustees) and administrative roles (Access Templates). Then, you define Managed Units and apply Access Templates, designating Trustees for each Managed Unit. You can also apply Access Templates to objects and folders in Active Directory, assigning the permissions to the necessary Trustees. This three-way relationship between Trustees, Access Templates, and managed objects is central to the implementation of your role-based administration model.
The Active Directory Users and Computers tool provides the facility to delegate administrative responsibilities. However, every time you want to delegate rights, you need to define a set of permissions. This makes the delegation procedure time-consuming and prone to errors. Active Roles overcomes this problem by consolidating permissions into customizable administrative roles, known as Access Templates. The logical grouping of permissions simplifies the management of delegation settings.
Access Templates are collections of permissions representing administrative roles. Permissions are used to allow or deny certain administrative operations to a user or group. You can create an Access Template that incorporates all permissions required to perform a particular administrative role.
To assign the role to a user or group, link the the Access Template to a Managed Unit, Organizational Unit, domain, or individual object, depending on the scope of the role, and then select a user or group to designate as a Trustee. As a result, the individual user, or each member of the group, acquires the rights specified by the role to administer objects that reside in the collection or folder to which the Access Template has been linked.
© ALL RIGHTS RESERVED. Feedback 使用条款 隐私 Cookie Preference Center
