UNIFYBroker/Microsoft Identity Manager Anchor Modification / Renames

Anchor Modification and Handling Renames

UNIFYBroker has a number of connectors which support anchor modification functionality, such as those which communicate with directory-based systems. Management agents derived from these systems can be configured to perform renames in the event that the value of an anchor field has changed (such as an account name). Often when an anchor changes, the resultant UNIFYBroker distinguished name will also change. There are a few considerations implementers need to make in this scenario:

  • UNIFYBroker will perform an update of the distinguished name in response to the modification of any fields used in the distinguished name (which is often the anchor field). Ensure that appropriate join criteria is set to ensure the rename process produces expected behaviour in the connector space.
  • It is important to ensure that provisioning logic does not provision the DN in a different format to that configured in the UNIFYBroker adapter engine - UNIFYBroker will prevent this from happening.
  • DNs in the connector space are case insensitive (see  http://msdn.microsoft.com/en-us/library/microsoft.metadirectoryservices.csentry.dn.aspx) - transient objects will occur if distinguished names only differ in casing.
  • The anchor field for UNIFYBroker management agents is the DN, as UNIFYBroker produces LDAP results during an import. If renames do occur on an import, the agent will instead process this as a delete of the entity with the old name and an add of the entity with the new name. This can be problematic for a few reasons:
    • The lineage of the entity is lost.
    • If the entity is to be exported later, it will require using a Delete operation. If the exporting agent authenticates as a user who does not have the Full Access Level, the agent will be unable to perform the Delete operation, although the Add Operation will succeed as normal and the target system may end up with extra entities.
    For these reasons, it is advised that a format for the distinguished names of entities is chosen such that they never change, or change as rarely as possible.

UNIFYBroker has a number of connectors which support anchor modification functionality, such as those which communicate with directory-based systems. Management agents derived from these systems can be configured to perform renames in the event that the value of an anchor field has changed (such as an account name). Often when an anchor changes, the resultant UNIFYBroker distinguished name will also change. There are a few considerations implementers need to make in this scenario:

  • UNIFYBroker will perform an update of the distinguished name in response to the modification of any fields used in the distinguished name (which is often the anchor field). Ensure that appropriate join criteria is set to ensure the rename process produces expected behaviour in the connector space.
  • It is important to ensure that provisioning logic does not provision the DN in a different format to that configured in the UNIFYBroker adapter engine - UNIFYBroker will prevent this from happening.
  • DNs in the connector space are case insensitive (see http://msdn.microsoft.com/en-us/library/microsoft.metadirectoryservices.csentry.dn.aspx) - transient objects will occur if distinguished names only differ in casing.
  • By default, the anchor field for UNIFYBroker management agents is the DN, as UNIFYBroker produces LDIF results during an import. However, if renames are to occur, the anchor will need to be changed to another field that uniquely identifies the user beyond the anchor changing, such as the IdBID. FIM throws an InvalidOperationException if it finds the anchor field and distinguished name have the same value during a rename (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms695437(v=vs.85).aspx). This can be done from the Set Anchor from on the Configure Attributes tab of the management agent.
CHECK: It is up to designers and implementers to ensure their selected field does not produce undesired behaviour in the rest of the identity management solution, and that rename behaviour is confirmed in DEV and UAT testing prior to production deployment.

Is this article helpful for you?