SUN/Oracle directory user entry DN rename (move) RRS feed

  • Question

  • Hi,

    Version FIM2010R2SP1 with latest publicly available hotfix rollup applied.

    Use case: Legacy enterprise directory (SUN iPlanet 5.2)  has users in different (ou) branches under the same tree depending on their current job. If they are transferred to another part of the organisation in the HR system, the requirement is to  move their user entry in this directory into a different ou.

    MA/Connector: Out of the box Sun/Oracle directory MA

    e.g. (dn) uid=hsmith001, ou=Sales,

    moved to:

    (dn) uid=hsmith001, ou=Cleaners,

    When the export is run to the connected directory, the "move" does actually happen in the connected source (the SUN directory server). So far so good.

    The connector space object is now marked as  'Awaiting export confirmation' (which is meant to occur on the next import).

    When an import is run, FIM creates a new connector space object with the new (renamed) dn but retains the existing object . At the same time it reports an error "ambiguous-import-flow-from-multiple-connectors" because it is seeing two objects with the same RDN (uid=hsmith). It has marked the original CS object for deletion.

    On the next synch, it says it has successfully deleted the original CS Object, however it is still there (and with the same anchor guid).

    It appears that with this connector connected to Sun Directory v5.1 and newer , you don't get to choose which attribute(s) you use for the anchor - it chooses the dn.

    It's puzzling why this issue exists in a technology set that has been around for years, so we are assuming that there is workaround or solution to this problem.

    N.B. This problem has been replicated on two completely independent environments by different people in our organisation.

    Any help/advice/suggestions would be most welcome.



    Wednesday, February 26, 2014 3:49 AM


  • We appear to have resolved this.

    Because the sun directory MA isn't the authoritative source for the Person object then the delete failed because the cs object was still connected to the MV object (unfortunately it failed silently).

    The dn and the anchor being the same (forced by the MA) FIM does an add (for the new renamed object) and delete (for the existing object). At least that's our interpretation.

    The solution is to use an MV extension and in code, disconnect the existing cs object and connect to the directory server and do the move (outside of FIM's knowledge.). Then everything will line up on subsequent import, sync as the disconnected cs.object which is no longer reflected in the connected source will be deleted.

    Maybe someone has a better description of this.

    Friday, February 28, 2014 2:12 AM