Identity Broker for Microsoft Identity Manager Anchor Modification / Renames

Anchor Modification and Handling Renames

Identity Broker 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 Identity Broker distinguished name will also change. There are a few considerations implementers need to make in this scenario:

  • Identity Broker 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 Identity Broker adapter engine - Identity Broker 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 Identity Broker management agents is the DN, as Identity Broker 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.

Identity Broker 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 Identity Broker distinguished name will also change. There are a few considerations implementers need to make in this scenario:

  • Identity Broker 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 Identity Broker adapter engine - Identity Broker 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 Identity Broker management agents is the DN, as Identity Broker 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?