Chat now with support
Chat with Support

Active Roles 7.5.2 - 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

Working with Federated Authentication

Federated Authentication allows users to access the application or web sites by authenticating them against a certain set of rules, known as claims. The authentication ticket or the token is used to validate the user across multiple application, web sites, or IT systems.

Claim-based authentication is a method to acquire the user identity related information on both on-premises and cloud-based products. A single token is created based on the predefined claims to identify the users trying to access the applications or web site. After the identification of the user is complete, a security token service is used to identify the type of user.

Active Roles supports federated authentication with Security Assertion Markup Language (SAML), through which you can sign in to an application once using the single sign-on option and you are authenticated to access websites.

For more information, see Appendix E: Enabling Federated Authentication

NOTE: While switching between the STS providers, restart IIS and clear the browser cache.

Configuring Federated Authentication settings

To configure the Federated Authentication settings, configure the Identity provider configuration, set claims in the Claim editor, and provide the Domain user login credentials.

Prerequisite
  • Ensure that the user has appropriate permissions to query the Active Directory. The same user must be provided in the Domain user login credentials field.

    • To set identity provider configuration

    1. In the Configuration Center main window, click Web Interface.

      The Web Interface page displays all the Web interface sites that are deployed on the Web server running the Web interface.

    2. To configure the federated authentication settings, click Authentication.

      The Site authentication settings page is displayed.

      NOTE:By default, the Default windows authentication settings is configured.

    3. To configure the federated authentication settings, click Federated.

    4. In the Identity provider configuration section, select the security Identity provider from the Identity provider drop-down menu. The available options are Azure, ADFS, and Custom.

    5. Select the required additional options from Options.

    6. Provide a valid URL in the Federated metadata URL field.

      NOTE:A federation metadata document is an XML document that conforms to the WS-Federation 1.2 schema. It exposes all data required for an STS implementer.

    7. To test the connection, click Test metadata.

      If the connection is successful, a message is displayed.

    8. To view the metadata URL, click Yes. To proceed further with the settings, click No.

    9. If you select the Token encryption from Options, you must enter the certificate thumbprint manually. If the option is not selected, this field is not available.

      NOTE:The certificate thumbprint key must be entered manually. Copying the key and pasting in the field is not supported.

    10. Provide the Realm URL of the requesting realm in the Realm field.

    11. Provide the URL to send a response in the Reply URL field. A URL that identifies the address at which the relying party (RP) application receives replies from the Security Token Service (STS).

    To set claims in the claim editor

    IMPORTANT:By default, the priority of the claim is set based on the order the claims are created. The claim created first has the first priority, the claim created next has the secondary priority, and so on. However, you can move the claims based on the required priority.

    1. In the Claim editor section, to add claims, click Add.

      Add claim window is displayed.

    2. Select the type of claim from the Claim type drop-down menu.

      IMPORTANT:UPN, SID, and email claims are supported.

    3. Select the Claim value.

    4. Provide a name for the claim in the Display name field.

    5. Provide a description in the Claim description field.

    6. Click Save.

      The claim is added successfully.

    NOTE:You can modify or remove the claims that are created.

    To provide the Domain user login credentials

    1. In the Domain user login credentials section, provide the valid credentials in the Username and Password fields.

    2. Click Modify to update the authentication settings.

      A message is displayed about the successful completion of the operation.

    After you click Modify, the ARSWeb is modified and is ready for federated authentication.

    For more information on using the Federated Authentication feature in multihop scenario, see Appendix E: Enabling Federated Authentication

    Role-based Administration

    Access Templates as administrative roles

    Active Roles provides safe, distributed administration through advanced delegation of rights with very 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 the Help Desk 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—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, you should link 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.

    Related Documents

    The document was helpful.

    Select Rating

    I easily found the information I needed.

    Select Rating