Skip to main content

Resource lifecycle management

Through Resource Lifecycle Management, OPS provides a simple way of creating, updating, and removing resources in target systems. RLM employs the logical key - or ODWLOGICKEY - which is a configurable key that can be used to match resource objects. This logical key works across Omada Identity components and is therefore relevant for OPS, ODW, and ES.

Creating resources in Active Directory is the primary scenario where Resource Lifecycle Management (RLM) is used. In the RLM, a resource is first created in ES and then in the target system through the OPS. When the resource is imported and subsequently exported, the ODWLOGICKEY helps to ensure that the resources are linked to each other as they represent the same object in the target system.

Data Object Lifecycle Management​

The Data Object Lifecycle Management (DOLM) is similar to the Resource Lifecycle Management, allowing however to create, update, and remove all types of data objects in the target system. It is utilized in the Active Directory to manage organizational units.

Shadow data objects​

Omada version badge Omada Cloud version badge

Shadow data objects are supported as resource types in provisioning task mappings. You can create provisioning tasks for calculated resource assignment types and define task mappings for them using Data Object Lifecycle Management code methods. This opens up new possibilities:

  • creation/single change in the calculated resource assignment (CRA) may trigger the creation of several provisioning tasks
  • change in the CRA in one system may create provisioning tasks in the other system
  • event definition filters provide control when the provisioning task should be created

Shadow data objects provide support for various scenarios that wouldn't otherwise be possible:

  • performing additional actions after an account is created (in the same or other system)
  • sending initial passwords to users using customer APIs
  • performing an update action only when a specific property is changed (for example, activating/deactivating)

Shadow data objects' advantages:

  • Improved automation: eliminates manual intervention by automatically creating provisioning tasks.
  • Enhanced security: ensures controlled password distribution.
  • Flexibility: supports advanced mapping (shadow objects) and custom workflows.
  • Reliability: prevents failure scenarios by ensuring accounts are created before credentials are sent.
  • Scalability: allows integration with additional APIs and external task management platforms.

Selecting the Data Object mapping type displays data objects prefixed with Calculated assignment for in the dropdown menu, indicating their nature.

Example - Password notification using REST API
  1. In the system onboarding view, enable provisioning. Configure all connector settings the and data model. Set secureStringType for password, for example:
<connectorDataModel xmlns="http://schemas.omada.net/ops/2015/ConnectorDataModelML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <properties>
    <property name="user" />
<property name="pass" dataType="secureStringType" />
  </properties>
  <objects>
    <object name="Password">
      <objectProperties>
        <objectProperty>user</objectProperty>
<objectProperty>pass</objectProperty>
      </objectProperties>
    </object>
  </objects>
</connectorDataModel>

  1. Add the task mapping for the calculated assignment account (from the system of your choice). You may need to set the Intial Password attribute on the account resource type attribute set for the attribute to be visible as the source in the task.

  2. Commit the settings.

  3. Go to Setup > Event definitions and click New. Enter the following details:

    • Event is triggered when: Choose the option matching your use case (for example, creation of calculated resource assignments; use filters for all conditions).
    • Triggers on objects of type: Choose the same object type as used in the task mappings.

  4. Add a new action. Select the option to execute the DataObjectLifeCycleManagement.SubmitProvisioningJob code method. In the code method parameters, provide UID of your password notification system.

Result: From now on, provisioning tasks for password notifications are created for new accounts.

Custom properties​

Custom properties are supported for the AdUser, AdGroup, and the AdOrgUnit objects. Any property that is not listed in the above tables is considered a custom property. To use custom properties, you must update the connector data model for the connector in the Enterprise Server. It is important that you specify the correct data here. After you have updated the data model, you must push the new configuration from the Enterprise Server to OPS.

General support for reference properties​

The OPS data model supports specification of reference properties. With reference properties, you can instruct the connector to perform a lookup for an object which id or anchor should be used to update a property on the object being provisioned.

Reference properties can be specified both for users as well as group tasks. These reference properties are used when you need to reference another active directory object from the object being created or updated. A common characteristic of all reference properties is that they need a distinguished name of the referred object, a value you seldom have available. When using reference properties, it is possible to look up the object and retrieve the distinguished name based on another available property value.

Reference properties are defined in the connector data model using data type referenceType. When defining the property to a part of an object, the properties referenceObject, referenceKeyProperty, and referenceLookupProperty are used to specify how to find the reference object. The below example presents how to lookup for the manager property based on the samAccountName:

<connectorDataModel xmlns="http://schemas.omada.net/ops/2015/ConnectorDataModelML">
  <properties>
    <property name="samAccountName"/>
    <property name="manager" dataType="referenceType"/>
  </properties>
  <objects>
    <object name="AdUser">
      <objectProperties>
        <objectProperty>samAccountName</objectProperty>
        <objectProperty
          referenceObject="User"
          referenceLookupProperty="samAccountName"
          referenceKeyProperty="distinguishedName">manager</objectProperty>
      </objectProperties>
    </object>
  </objects>
</connectorDataModel>

The following example presents how to add a nested group using the member property to a group based on the samAccountName of the group:

<connectorDataModel xmlns="http://schemas.omada.net/ops/2015/ConnectorDataModelML">  
    <properties>    
        <property name="samAccountName"/>    
        <property name="member" multiValued="true" dataType="referenceType"/>  
        </properties>  
            <objects>    
                <object name="AdGroup">      
                    <objectProperties>        
                        <objectProperty>samAccountName<objectProperty>        
                        <objectProperty          
                            referenceObject="Group"          
                            referenceLookupProperty="samAccountName"          
                            referenceKeyProperty="distinguishedName">member
                        </objectProperty>     
                    </objectProperties>    
                </object>  
            </objects>
</connectorDataModel>

Multivalued reference properties are also supported. You must specify the Active Directory objectClass name in referenceObject and not the data model object name. The lookup supports any objectClass, as well as, custom object classes.

Troubleshooting​

In cases where you use a non-domain administrator for provisioning, the error message Access denied may appear when you provision new Active Directory users. The reason for this is that passwords are required when you create users as a less privileged user, that is a non-domain administrator. At the same time, you must also indicate in the configuration that it is not allowed to have blank passwords.

To resolve this situation, add a line to the Active Directory task mapping where you set the property passwordNotRequired to False. For more information about how to create a granular password policy, see AD DS: Fine-Grained Password Policies in the Microsoft documentation.