Chat now with support
Chat with Support

Active Roles 8.1.1 - Administration Guide

Introduction 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
Provisioning Policy Objects Deprovisioning Policy Objects How Policy Objects work Policy Object management tasks Policy configuration tasks
Property Generation and Validation User Logon Name Generation Group Membership AutoProvisioning Exchange Mailbox AutoProvisioning AutoProvisioning in SaaS products OneDrive Provisioning Home Folder AutoProvisioning Script Execution Microsoft 365 and Azure Tenant Selection E-mail Alias Generation 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
Using rule-based and role-based tools for granular administration Workflows
Key workflow features and definitions About workflow processes Workflow processing overview Workflow activities overview Configuring a workflow
Creating a workflow definition for a workflow Configuring workflow start conditions Configuring workflow parameters Adding activities to a workflow Configure 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
Approval workflow Email-based approval Automation workflow Activity extensions
Temporal Group Memberships Group Family Dynamic groups Active Roles Reporting Management History Entitlement profile Recycle Bin AD LDS data management One Identity Starling Join and configuration through Active Roles Managing One Identity Starling Connect Configuring linked mailboxes with Exchange Resource Forest Management Configuring remote mailboxes for on-premises users Azure AD, Microsoft 365, and Exchange Online Management
Configuring Active Roles to manage Hybrid AD objects Managing Hybrid AD users
Creating a new Azure AD user with the Web Interface Viewing or updating the Azure AD user properties with the Web Interface Viewing or modifying the manager of a hybrid Azure user Disabling an Azure AD user Enabling an Azure AD user Deprovisioning of an Azure AD user Undo deprovisioning of an Azure AD user Adding an Azure AD user to a group Removing an Azure AD user from a group View the change history and user activity for an Azure AD user Deleting an Azure AD user with the Web Interface Creating a new hybrid Azure user with the Active Roles Web Interface Converting an on-premises user with an Exchange mailbox to a hybrid Azure user Licensing a hybrid Azure user for an Exchange Online mailbox Viewing or modifying the Exchange Online properties of a hybrid Azure user Creating a new Azure AD user with Management Shell Updating the Azure AD user properties with the Management Shell Viewing the Azure AD user properties with the Management Shell Delete an Azure AD user with the Management Shell Assigning Microsoft 365 licenses to new hybrid users Assigning Microsoft 365 licenses to existing hybrid users Modifying or removing Microsoft 365 licenses assigned to hybrid users Updating Microsoft 365 licenses display names
Unified provisioning policy for Azure M365 Tenant Selection, Microsoft 365 License Selection, Microsoft 365 Roles Selection, and OneDrive provisioning Microsoft 365 roles management for hybrid environment users Managing Microsoft 365 contacts Managing Hybrid AD groups Managing Microsoft 365 Groups Managing cloud-only distribution groups Managing cloud-only dynamic distribution 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 cloud-only shared mailboxes
Modern Authentication Managing the configuration of Active Roles
Connecting to the Administration Service 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 Integrating Active Roles with other products and services Active Roles Language Pack Active Roles Diagnostic Tools Active Roles Add-on Manager

AD LDS data management

Active Roles provides the ability to manage directory data in Microsoft Active Directory Lightweight Directory Services (AD LDS), an independent mode of Active Directory formerly known as Active Directory Application Mode (ADAM).

A running copy of the AD LDS directory service is referred to as a service instance (or, simply, instance). To use Active Roles for managing data hosted by the AD LDS directory service, you first need to register the instance that holds the data to manage.

Once an instance has been registered, the Active Roles client interfaces—Console, Web Interface and ADSI Provider—can be used to access, view and modify directory data in the application and configuration partitions found on the instance. The instances registered with Active Roles are referred to as managed AD LDS instances.

To register an AD LDS instance with Active Roles

  1. Open the Active Roles Console.

  2. In the Console tree, expand Configuration > Server Configuration, right-click Managed AD LDS Instances (ADAM), and select New > Managed AD LDS Instance (ADAM) to start the Add Managed AD LDS Instance Wizard.

  3. Follow the instructions on the wizard pages.

  4. On the AD LDS Instance to Register page, specify the server name and port number of the AD LDS instance you want to register with Active Roles.

    In Server, type the fully qualified DNS name (for example, server.company.com) of the computer on which the instance is running. In LDAP port, type the number of the Lightweight Directory Access Protocol (LDAP) communication port in use by the instance (the default communication port for LDAP is 389). You can also click Select to locate and select the AD LDS instance you want to register.

  5. On the Active Roles Credentials page, specify the credentials that Active Roles will use to access the instance.

    If you want each Administration Service to connect to the instance in the security context of its own service account, click The service account information the Administration Service uses to log on. With this option, different Administration Services may have different levels of access to the instance (the service account of one Service may have administrative rights on the instance while the service account of another Service may not). As a result, switching from one Administration Service to another may cause Active Roles to lose access to the instance.

    If you want each Administration Service to connect to the instance using the same user account, click The Windows user account information specified below and type in the user name, password, and domain name. In this way, you specify a so-called override account, thereby causing the access rights of Active Roles on the instance to be determined by the access rights of that user account (rather than by those of the service account of the Administration Service).

  6. On the completion page, click Finish to start the registration process.

The override account you specify in Step 5 must, at a minimum, be a member of the following groups in the AD LDS instance:

  • Instances (CN=Instances,CN=Roles) in the configuration partition.

  • Readers (CN=Readers,CN=Roles) in the configuration partition and in each application partition.

If you choose not to specify an override account, you should add the service account to these groups.

To allow Active Roles full access to the AD LDS instance, add the service account or, if specified, the override account to the following group:

  • Administrators (CN=Administrators,CN=Roles) in the configuration partition

If you add the account to the Administrators group, you don’t need to add it to the Instances or Readers group.

Use the AD LDS ADSI Edit console to add the account to the appropriate groups prior to registering the instance with Active Roles.

After an AD LDS instance is registered, you can view or change its registration settings by using the Properties command on the object representing that instance in the Managed AD LDS Instances (ADAM) container. Thus, you can make changes to the choices that were made in Step 5 of the above procedure.

If you no longer want to manage an AD LDS instance with Active Roles, you can unregister the instance by using the Delete command on the object representing that instance in the Managed AD LDS Instances (ADAM) container. Unregistering an instance only removes the registration information from Active Roles, without making any changes to the directory data within that instance.

Managing AD LDS objects

The application and configuration partitions found in the managed AD LDS instances are grouped together in a top-level container, thus making it easy to locate the AD LDS data. Each partition is represented by a separate container (node) so you can browse the partition tree the same way you do for an Active Directory domain.

The Active Roles console supports a wide range of administrative operations on AD LDS users, groups and other objects, so you can create, view, modify, and delete directory objects, such as users, groups and Organizational Units, in the managed AD LDS instances the same way you do for directory objects in Active Directory domains.

To browse the directory tree and manage AD LDS objects

  1. In the Console tree under the Console tree root, double-click the AD LDS (ADAM) container.

  2. In the Console tree under AD LDS (ADAM), double-click a directory partition object to view its top-level containers.

  3. In the Console tree, double-click a top-level container to view the next level of objects in that container.

  4. Do one of the following:

    • To move down a directory tree branch, continue double-clicking the next lowest container level in the Console tree.

    • To administer a directory object at the current directory level, right-click the directory object in the details pane and use commands on the shortcut menu.

In the AD LDS (ADAM) container, each directory partition is identified by a label that is composed of the name of the partition, the DNS name of the computer running the AD LDS instance that hosts the partition, and the number of the LDAP port in use by the instance.

Normally, the console only displays the application directory partitions. To view the configuration partition, switch into Raw view mode: select View > Mode, click Raw Mode, and then click OK.

You can only perform the data management tasks to which you are assigned in Active Roles. Thus, you are only shown the commands you are authorized to use and the objects you are authorized to view or modify.

In addition to access control, Active Roles provides for policy enforcement on directory data. Policies may restrict access to certain portions of directory objects, causing data entry to be limited with choice constraints, auto-generating data without the ability to modify the data, or requiring data entry. The Console provides a visual indication of the data entries that are controlled by policies: the labels of such data entries are underlined on the dialog boxes so that the user can examine policy constraints by clicking a label.

Adding an AD LDS user to the directory

To enable the creation of users in AD LDS, the administrator should first import the optional definitions of user object classes that are provided with AD LDS. These definitions are provided in importable .ldf files (ms-User.ldf, ms-InetOrgPerson.ldf, ms-UserProxy.ldf), which can be found on the computer running the AD LDS instance. Alternatively, the software designers can extend the AD LDS schema with their custom definitions of AD LDS user object classes. Details on how to extend the AD LDS schema can be found in Microsoft’s documentation that comes with AD LDS.

To add an AD LDS user to the directory

  1. In the Console tree, under AD LDS (ADAM), right-click the container to which you want to add the user, and then select New > User to start the wizard that will help you perform the user creation task.

  2. Follow the instructions on the wizard pages to set values for user properties.

  3. If you want to set values for additional properties (those for which the wizard pages do not provide data entries), click Edit Attributes on the completion page of the wizard.

  4. After setting any additional properties for the new user, click Finish on the completion page of the wizard.

By default, an AD LDS user is enabled when the user is created. However, if you assign a new AD LDS user an inappropriate password or leave the password blank, the newly created AD LDS user account may be disabled. Thus, an AD LDS instance running on Windows Server 2003 automatically enforces any local or domain password policies that exist. If you create a new AD LDS user, and if you assign a password to that user that does not meet the requirements of the password policy that is in effect, the newly created user account will be disabled. Before you can enable the user account, you must set a password for it that meets the password policy restrictions. The instructions on how to set the password for an AD LDS user and how to enable an AD LDS user are given later in this section.

Adding an AD LDS group to the directory

AD LDS provides default groups, which reside in the Roles container of each directory partition in AD LDS. You can create additional AD LDS groups as necessary. New groups can be created in any container.

To add an AD LDS group to the directory

  1. In the console tree, under AD LDS (ADAM), right-click the container to which you want to add the group, and then select New > Group to start the wizard that will help you perform the group creation task.

  2. Follow the instructions on the wizard pages to set values for group properties.

  3. If you want to set values for additional properties (those for which the wizard pages do not provide data entries), click Edit Attributes on the completion page of the wizard.

  4. After setting any additional properties for the new group, click Finish on the completion page of the wizard.

You can add both AD LDS users and Windows users to the AD LDS groups that you create. For instructions, see the sub-section that follows.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating