Skip to main content

Additional information and troubleshooting

Here you can find additional configuration information and tips allowing you to solve possible troubles with the Microsoft Active Directory connectivity in Omada Identity.

Custom properties

Custom properties are supported for the AdUser, AdGroup, and the AdOrgUnit objects. Any property that is not listed in the corresponding 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 whose id or anchor should be used to update a property on the object being provisioned.

Reference properties can be specified both for users and 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 example below presents how to look up 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.

Log entry for failing domain controller

When a domain controller is out of commission, the Microsoft API that the is calling should automatically assign other, viable, domain controller.

To verify which domain controller is failing search the domain controller phrase in the Message column in import log. There you can see which message was returned from Microsoft DirSync API.