Share via

Dealing with OpenLDAP XMA 1.1: Avoiding duplicate-object errors and bad csentry object type

  • Article

When you first try to import from an LDAP using this XMA, you may get duplicated objects. This is due to the way the XMA builds the LDAP queries that creates to perform object discovery: it will find the same object several times due to matching several object classes.

You can fix it by tweaking the "Map Object Types" dialog in your XMA and also adjusting the undocumented excludedTypes parameter.

The XMA builds a search filters hashtable with object types (not object classes you have in your LDAP) specified in "Map Object Types" dialog as the objectclass to search for. It excludes there those object types specified in the excludedTypes custom parameter.

In the default configuration, object types are “organizationalUnit”, “top”, “inetOrgPerson” and “organizationalRole”, and "top" is in ExcludedTypes.

Therefore, the XMA performs one search per non-excluded object type, per naming context, such as: "(|(objectclass=inetOrgPerson))" "(|(objectclass=organizationalRole))" "(|(objectclass=organizationalUnit))".

When defining the object class to object type mapping, you have to specify all possible sequences (or begening part of sequences) as they appear in the import file, and map to the desired object type. This makes the csentry object type to be mapped properly to the object type you want to (so your rules can work based on object types), otherwise you end up seeing users as "top" object types, and such. Also carefully exclude in excludedTypes those object classes that render a single object to be found more than once as per search filters.

For example, if your users objects can be like three sets of object classes:

<attr name="objectClass">

  <value>top</value>

  <value>person</value>

  <value>organizationalPerson</value>

  <value>CustomPerson</value>

  <value>mdsCVLink</value>

  <value>wdmperson</value>

  <value>mdsMVLink</value>

  <value>inetOrgPerson</value>

  <value>mdsSelfCareUser</value>

  <value>CpPSMPrefs</value>

  <value>CpEMIPrefs</value>

  <value>CpUSRUserRecordAbs</value>

  <value>CpUSRUserRecordAux</value>

</attr>

 

<attr name="objectClass">

  <value>top</value>

  <value>person</value>

  <value>organizationalPerson</value>

  <value>CustomPerson</value>

  <value>mdsCVLink</value>

  <value>inetOrgPerson</value>

  <value>mdsSelfCareUser</value>

  <value>CpPSMPrefs</value>

  <value>CpEMIPrefs</value>

  <value>CpUSRUserRecordAbs</value>

  <value>CpUSRUserRecordAux</value>

</attr>

 

<attr name="objectClass">

  <value>top</value>

  <value>person</value>

  <value>organizationalPerson</value>

  <value>CustomPerson</value>

  <value>mdsCVLink</value>

  <value>wdmperson</value>

  <value>mdsMVLink</value>

  <value>CpPSMPrefs</value>

  <value>CpEMIPrefs</value>

  <value>CpUSRUserRecordAbs</value>

</attr>

You can specify as mapping "top,person,organizationalPerson,CustomPerson" –> “CustomPerson”. This will map all three "supersets" of object classes to CustomPerson, providing that the mapping matches the begining values of objectClass tag.

However, if an object for some reason comes in the DSML like:

<attr name="objectClass">

  <value>top</value>

  <value>person</value>

  <value>CustomPerson</value>

  <value>organizationalPerson</value>

  <value>mdsCVLink</value>

  <value>wdmperson</value>

  <value>mdsMVLink</value>

  <value>CpPSMPrefs</value>

  <value>CpEMIPrefs</value>

  <value>CpUSRUserRecordAbs</value>

</attr>

You will need to specify an additional mapping like  "top,person,CustomPerson,organizationalPerson" –> “CustomPerson”, or you will see your customPerson objects to be mapped to an unwanted object type. You can check if this is occurring by performing a “Search Connector Space” and sort by object type.