Chatee ahora con Soporte
Chat con el soporte

Active Roles 8.0.1 LTS - Administration Guide

Introduction About Active Roles Getting Started Rule-based Administrative Views Role-based Administration
Access Templates as administrative roles Access Template management tasks Examples of use Deployment considerations Windows claims-based Access Rules
Rule-based AutoProvisioning and Deprovisioning
About Policy Objects Policy Object management tasks Policy configuration tasks
Property Generation and Validation User Logon Name Generation Group Membership AutoProvisioning E-mail Alias Generation Exchange Mailbox AutoProvisioning AutoProvisioning for SaaS products OneDrive Provisioning Home Folder AutoProvisioning Script Execution Office 365 and Azure Tenant Selection User Account Deprovisioning Office 365 Licenses Retention Group Membership Removal Exchange Mailbox Deprovisioning Home Folder Deprovisioning User Account Relocation User Account Permanent Deletion Group Object Deprovisioning Group Object Relocation Group Object Permanent Deletion Notification Distribution Report Distribution
Deployment considerations Checking for policy compliance Deprovisioning users or groups Restoring deprovisioned users or groups Container Deletion Prevention policy Picture management rules Policy extensions
Workflows
Understanding workflow Workflow activities overview Configuring a workflow
Creating a workflow definition Configuring workflow start conditions Configuring workflow parameters Adding activities to a workflow Configuring an Approval activity Configuring a Notification activity Configuring a Script activity Configuring an If-Else activity Configuring a Stop/Break activity Configuring an Add Report Section activity Configuring a Search activity Configuring CRUD activities Configuring a Save Object Properties activity Configuring a Modify Requested Changes activity Enabling or disabling an activity Enabling or disabling a workflow Using the initialization script
Example: Approval workflow E-mail based approval Automation workflow Activity extensions
Temporal Group Memberships Group Family Dynamic Groups Active Roles Reporting Management History
Understanding Management History Management History configuration Viewing change history
Workflow activity report sections Policy report items Active Roles internal policy report items
Examining user activity
Entitlement Profile Recycle Bin AD LDS Data Management One Identity Starling Management Managing One Identity Starling Connect Configuring linked mailboxes with Exchange Resource Forest Management Configuring remote mailboxes for on-premises users Azure AD, Office 365, and Exchange Online management
Configuring Active Roles to manage hybrid AD objects Managing Hybrid AD Users Unified provisioning policy for Azure O365 Tenant Selection, Office 365 License Selection, and Office 365 Roles Selection, and OneDrive provisioning Office 365 roles management for hybrid environment users Managing Office 365 Contacts Managing Hybrid AD Groups Managing Microsoft 365 Groups Managing Azure Security Groups Managing cloud-only distribution groups Managing cloud-only Azure users Managing cloud-only Azure guest users Managing cloud-only Azure contacts Changes to Active Roles policies for cloud-only Azure objects Managing room mailboxes Managing cloud-only shared mailboxes
Managing Configuration of Active Roles
Connecting to the Administration Service Adding and removing managed domains Using unmanaged domains Evaluating product usage Creating and using virtual attributes Examining client sessions Monitoring performance Customizing the console Using Configuration Center Changing the Active Roles Admin account Enabling or disabling diagnostic logs Active Roles Log Viewer
SQL Server Replication Using regular expressions Administrative Template Communication ports Active Roles and supported Azure environments Active Roles integration with other One Identity and Quest products Active Roles integration with Duo Active Roles integration with Okta Active Roles Language Pack Active Roles Diagnostic Tools Active Roles Add-on Manager

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

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))

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.

 

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación