Chat now with support
Chat with Support

Active Roles 7.5.4 - 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 One Identity Starling Two-factor Authentication for Active Roles Managing One Identity Starling Connect 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 Office 365 Groups Managing Azure Security 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 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 Appendix A: Using regular expressions Appendix B: Administrative Template Appendix C: Communication ports Appendix D: Active Roles and supported Azure environments Appendix E: Enabling Federated Authentication Appendix F: Active Roles integration with other One Identity and Quest products Appendix G: Active Roles integration with Duo Appendix H: Active Roles integration with Okta

Delegation in a functional environment

In a functional environment there is a separate group of administrators for each function. So there may be a group for managing users, a helpdesk, domain administrators, and Exchange administrators. In case of a functional environment, you need to decide on a certain role for each function. These roles usually cross Organizational Unit boundaries so delegation is typically done at the root of the domain or domains. Typically a delegation model for this scenario would look something like the following:

Table 11: Delegation model in a functional environment

Location / Template

Permission

Delegate (Trustee)

Domain / Read All Objects
  • All Objects - List
  • All Objects - Read All Properties
  • Domain - Write LDAP Server Property (permission to change Operational Domain Controller)

Authenticated Users

Domain / User Admin
  • User Objects - Full Control
  • Organizational Unit - Create/Delete User Objects

User Admin group

Domain / Group Admin
  • Group Objects - Full Control
  • Organizational Unit - Create/Delete Group Objects

Group Admin group

Delegation in a hosted environment

In a hosted environment there is an admin group or set of admin groups responsible for each top-level Organizational Unit (OU). In this case administrators may not want others to see what is going on in their OU structure. Active Roles can accommodate this easily. Since except for the Active Roles administrators no one has any default rights, a delegation model may look something like the following:

Table 12: Delegation model in a hosted environment

Location / Template

Permission

Delegate (Trustee)

Domain / Read Domain
  • Domain - List
  • Domain - Read All Properties
  • Domain - Write LDAP Server Property

Authenticated Users

Top-level OU / OU Admin
  • All Objects - List
  • All Objects - Read all Properties
  • Organizational Unit - Create/Delete User/Group Objects
  • User Objects - Full Control
  • Group Objects - Full Control

OU Admin

With this delegation model, everyone can see the domain and change the domain controller they are using for management. However, below that only the OU admin can see their associated OU. This keeps administrators from seeing or managing anything outside of their control.

More than likely a delegation model would incorporate features of both. For instance, you may have a hosted environment where each business unit is responsible for their own Active Directory management, with a central helpdesk to perform basic user and group management tasks.

Lastly is the issue of syncing permission to Active Directory. Although Active Roles enables you to accomplish this task, it is a better idea to keep all of the permissions within Active Roles for the following reasons:

  • This protects your Active Directory. Directory-enabled applications can be modified to use the Active Roles ADSI Provider allowing for granular access to only the data and areas that are needed. Doing so helps prevent malicious software from destroying data in Active Directory.
  • This ensures directory integrity. By forcing all administrators to use Active Roles, you ensure that all policies, such as naming standards, are correctly enforced.
  • This gives a complete auditing picture. By having all applications and administrators use Active Roles’ interfaces, you ensure that Active Roles’ Report Data Collector can gather every action that happens in the directory, down to the attribute level.

 

Windows claims-based Access Rules

Active Roles introduces claims-based authorization rules (access rules) to allow or deny access to Active Directory objects depending on the attributes of the identity attempting to access those objects. Built on the concept of Dynamic Access Control (DAC), this feature enables Active Roles to recognize and evaluate the attribute-based claims of the identity that requests access to data held in Active Directory.

Access rules improve access control management for Active Directory administration. With access rules, Active Roles adds more flexibility and precision in delegating control of Active Directory objects, such as users, computers or groups, through the use of claims—that is, Active Directory user and computer properties—in the Active Roles authorization model.

By using access rules, you can control access to Active Directory objects based on the characteristics of both the objects and the delegated administrators requesting access to the objects. This feature enables you to define and enforce very specific requirements for granting administrative access to Active Directory data. For example, you can easily restrict access of delegated administrators to user accounts whose properties (such as department or country) match the properties of the delegated administrator’s account in Active Directory.

Access rules help you create more complete access controls on Active Directory objects by comparing object properties with user and device claims. A domain controller issues claims to an identity that consist of assertions based on the properties of that identity retrieved from Active Directory. When an identity requests access to a particular object, Active Roles evaluates the claims of that identity and the properties of that object against the access rules, and then, depending upon the evaluation results, applies the appropriate Access Templates to make an authorization decision.

Understanding Access Rules

Access rules enable administrators to apply access-control permissions and restrictions based on well-defined conditions that can include the properties of the target objects, the properties of the user who requests access to target objects, and the properties of the device from which the user requests access to target objects. For example, when the user’s role or job changes (resulting in changes to the attributes of the user’s account in Active Directory), access rules can cause the user’s permissions to change dynamically without additional intervention from the administrator.

An access rule is an expression of authorization rules that can include conditions that involve user groups, user claims, device groups, device claims, and target object properties. When you apply an Access Template, you can use an access rule to determine the conditions that must be satisfied for the permissions resulting from the Access Template to take effect.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating