The area where Active Roles collects product usage statistics is referred to as managed scope. By default, managed scope comprises all Active Directory domains and AD LDS instances registered with Active Roles. This means that by default product usage statistics includes all enabled user accounts in all managed domains and instances. However, if you don’t use Active Roles to manage a particular domain or instance, or a part of a domain or instance (for example, individual Organizational Units), then you can exclude the entire domain or instance, or a part of a domain or instance, from managed scope.
Active Roles provides a built-in Policy Object allowing you to exclude entire AD domains, AD LDS directory partitions, individual Organizational Units (OUs), or even Managed Units (MUs) from managed scope. This Policy Object is located in the Configuration/Policies/Administration/Builtin container in the Active Roles console, and has the name Built-in Policy - Exclude from Managed Scope. When applied to a container such as an AD domain, AD LDS directory partition, OU or MU, this Policy Object:
Thus, you can exclude a certain domain from managed scope by applying a Policy Object: Choose the Enforce Policy command on the domain object under the Active Directory node in the Active Roles console, click Add, and select the Built-in Policy - Exclude from Managed Scope Policy Object. This stops product usage statistics from counting objects in that domain, and makes all objects in that domain available for read access only. You will not be able to create new objects (users, groups, computers, and so forth) or make changes to existing objects in that domain by using Active Roles.
After you have excluded a domain from managed scope, you may need to make a particular OU in that domain available for read/write access. You can accomplish this by blocking policy inheritance: In the Active Roles console, choose the Enforce Policy command on the OU and then select the Blocked option next to Built-in Policy - Exclude from Managed Scope. Doing so removes the read-only restriction from the OU and objects it contains, while causing product usage statistics to start counting objects held in that OU.
When you apply the Built-in Policy - Exclude from Managed Scope Policy Object to a Managed Unit, all objects that match the membership rules of that Managed Unit are excluded from managed scope. You can use this option to prevent product usage statistics from counting objects that satisfy certain conditions (for example, user accounts that have a particular country or department setting): Create a Managed Unit with the appropriate membership rules and then apply the Built-in Policy - Exclude from Managed Scope Policy Object to that Managed Unit. Doing so stops product usage statistics from counting objects that match the Managed Unit’s membership rules, while making those objects read-only.
You can determine whether a given object is excluded from managed scope by looking at the Managed field on the Object tab in the Properties dialog box for that object in the Active Roles console or on the General Properties page in the Active Roles Web Interface. If the object is excluded from managed scope, the Managed field reads No; otherwise, the field reads Yes.
By default, Active Roles does not limit the number of managed objects. However, as Active Roles’ license fee is based on the managed object count, you may need to verify if the object count is under a certain threshold. You can perform this task by specifying a threshold value for the number of managed objects. The scheduled task that counts managed objects then raises an alert each time it detects that the current number of managed objects exceeds the threshold value. The alert makes the Product Usage Statistics section red on the root page in the Active Roles console, and can send a notification over e-mail.
To configure thresholds and notification for the managed object count
Only members of the Active Roles Admin account are authorized to configure thresholds and notification for the managed object count.
The console does not display the Change link unless you are logged on as Active Roles Admin.
You can specify an AD DS threshold value and an AD LDS threshold value independently from each other. Active Roles raises an alert if the total number of managed objects in Active Directory domains or AD LDS directory partitions exceeds the corresponding threshold value. You may specify a threshold value for AD DS or AD LDS only. In this case, Active Roles only evaluates the managed object count for Active Directory domains or AD LDS directory partitions, respectively. If neither AD DS threshold value nor AD LDS threshold value is specified, then Active Roles does not evaluate the managed object counts at all.
If multiple mail configuration objects exist in your Active Roles environment, then you may first need to select the appropriate object from the E-mail server settings list. Mail configuration objects can be created in the Configuration/Server Configuration/Mail Configuration container in the Active Roles console.
The Active Roles console allows you to set a text label that helps you identify your Active Roles installation in the Managed Object Statistics report—a report that lists the managed object counts (see Viewing product usage statistics). You can use the installation label to distinguish, for example, between production and non-production or pilot installations. The label text is displayed in the title of the Managed Object Statistics report.
To set or change the installation label
Only members of the Active Roles Admin account are authorized to set or change the installation label.
The console does not display the Change link unless you are logged on as Active Roles Admin.
Active Roles provides the facility to define custom (virtual) attributes for any existing object type. This allows additional object properties to be specified without extending the Active Directory schema. For example, custom attributes can be used to store specific user data.
You can configure a virtual attribute to store the attribute value in the Active Roles database. Otherwise, to use the virtual attribute, you need to implement a script policy to handle the attribute value.
In the Unique X.500 object ID box, you can optionally change the default value of the attributeID property (OID) for the new attribute. The default value is generated automatically. If you want to generate your own value, you can use the Oidgen (oidgen.exe) tool, included with the Windows Server Resource Kit.
In the Schema ID GUID box you can optionally change the default value of the schemaIDGUID property. The default value is generated automatically. If you want the new attribute to have the fixed schemaIDGUID property, replace the default value with your own value. For example, you can generate GUID with the Uuidgen tool, included with the Microsoft Platform SDK.
If you need the new attribute to be associated with object classes that are not listed by default, select the Show all possible classes check box.
If you choose not to store the attribute values in the database, a script policy is required to supply the attribute value when retrieving the attribute and to save the attribute value when updating the attribute.
However, you should use this option carefully. Storing attribute values in the Active Roles configuration database may considerably increase the database size.
This option can be modified after the attribute is created, by managing properties of the virtual attribute.
After the new virtual attribute has been added, reconnect to the Administration Service. The new virtual attribute appears in the Virtual Attributes container under Configuration/Server Configuration.
To view or modify the value of a virtual attribute on an object
© 2021 One Identity LLC. ALL RIGHTS RESERVED. Feedback 이용 약관 개인정보 보호정책