Understanding Object Identifiers: Anchor and DN

  • Article

Objects are identified with up to two different identifiers, anchor and dn. An anchor is an immutable (cannot be changed) unique identifier and is mandatory for an object. Which attribute, or attributes, is used for the anchor is defined on the management agent. Which attribute is used for the dn is defined in the schema. The dn is the attribute which other objects will use to refer to this object and it is mutable (can be changed). The dn attribute is despite its name not necessarily in LDAP dn style. If the anchor is also the value used by other objects to reference it, then no DN is needed.

The existence and format of the dn attribute is defined by the MA Capability dnStyle. dnStyle can have the following values:

Value Description

None

The management agent does not have a separate dn attribute. The anchor is used for references between objects. Objects cannot be renamed.

Generic

The management agent has a dn. It can be of type string, integer or binary but it is not in LDAP style. Object renames are allowed.

LDAP

The management agent has a dn and it is of LDAP style. An LDAP style dn allows the interface GetHierarchy to be used and that Provisioning Hierarchy is enabled. Object renames are allowed.

Setting anchor and dn values

The anchor is set either in provisioning code or returned from the connected system during export. If the anchor is a constructed (concatenated) anchor then all components of the anchor must have a value. For Generic and LDAP dnStyle the dn must be set in provisioning code. An object must have an anchor after export. If there isn’t an anchor for an object, an error will be thrown.

The provisioning code will be different depending on the scenario:

  • Example: Connected Data Sources that Expect server to Provide the Anchor Attributes

  • Example: Connected Data Sources that Generate the Anchor Attributes

  • Example: Connected Data Sources that Generate the Anchor Attributes

The MA’s export code will also be different depending on the scenario:

  • Example: Connected Data Sources that Generate the Anchor Attributes

  • Example: Connected Data Source Changes the dn during export

Anchor attributes cannot be changed in provisioning code or EAF once the object has been exported.

The following table lists errors the Sync Engine can return with respect to anchor issues.

Error Description

E_MMS_MA_MULTI_VALUED_ANCHOR_COMPONENT

The anchor attribute is made of multi-valued attributes.

E_MMS_MA_MISSING_ANCHOR_COMPONENT

One of the anchor attributes is empty and was not returned by the connected system during export.

E_MMS_MA_ANCHOR_TOO_LONG

E_MMS_STORE_EXPORT_ASSIGN_DUPLICATE_ANCHOR

During export an anchor was returned already in use.

The following table lists errors the Sync Engine can return with respect to dn issues.

Error Description

E_MMS_MA_INVALID_DN

Returned when the dn is not valid LDAP.

E_MMS_STORE_EXPORT_ASSIGN_DUPLICATE_DN

During export an anchor was returned already in use.

Import changes to anchor and DN

During full and delta import it is possible that a change to an attribute which is making up the anchor is read. If an anchor attribute is changed it is treated as a new object. During Full Import the new object is created and the old object is obsoleted (deleted at the end of Full Import). During Delta Import and if an update to an anchor attribute is received the cs object is transformed into a transient object and the MA Import method will be called with an ObjectFullImport request with the new anchor value. The transient object will be removed by an explicit delete or during Full Import.

If a change to the dn is detected and the dnStyle is Generic or LDAP then this is treated as an object rename.