LDAP driver: openldap 'move' operation being detected as 'add' then 'delete

We are configuring an IDM LDAP driver to integrate with an openldap directory.  We are using the ldapsearch method as the directory does not support changelog. 

I believe because of the nature of the polling, move events in openldap are being seen by the driver as 'add' events followed by 'delete' events(or vice-versa - I don't know if we can reliably predict the order). 

Has anyone come across this behaviour while integrating with LDAP directories that do not support changelog?  What is the best way to manage this?  particularly in the case where we cannot reliably determine if a delete operation is an actual delete operation or whether the object has simply been moved.

FYI - our primary use case concerning moves is that  if a user moves in openldap between two particular containers we also wish to move the user in the IDVault.   Currently, with the driver interpreting this as an add then a delete, I fail to see how we achieve this?


  • You could use the AD Driver approach.  Cache the current OpenLDAP location (DN format) in an attribute like DirXML-ADContext (where AD driver does it).

    Then on a move/rename it parse DN's the first node (CN=) and then the rest (ou=users,dc=acme,dc=com) and you compare  If the CN has changed, rename  If the rest has changed, move. 

    Now the association value in your LDAP driver, is it a GUID of the LDAP DN?  I think it is LDAP DN which makes this a bit awkward, since the Assoc value like changed... 

    You MIGHT need to consider every add event as a re-match.  Just letting it flow naturally will error since your target user is already associated.  So you would have to check in the Match policy, before the do-find-matching, by Querying, checking if it is associated, and then maybe fixing it.  I have to think about how I would do that. Not sure at this second.  But a good start.

  • thanks for the response, it's helped me think through this a bit better.  The association value is the DN btw.  

    So I think I'll try this approach:

    On the "add" event I can do the following:

    1. query for a matching object

    2. check if it's already associated

    3. if associated: 

       update the association with the new DN
       write the new context to my custom attribute -say "LDAPContext"
       move the object directly in the vault
       veto the add operation.  

    On the  "delete" operation:

    1. query for a matching object in the vault

    2. check if the "LDAPContext" is different to the context parsed from src-dn

    3. veto if the context is different. 


    This will work if the add comes before the delete but if the delete comes first LDAPContext will have the same value - and my object will then be deleted in the vault.  

    The only way round this I can think of is  that on a delete operation, rather than letting the delete  flow through we get the driver to create a WorkOrder which will delete the object after a specified period of time.  If a related "add" operation then comes through the WO can be deleted and the object will be retained.  Seems a bit complex though...


    anyway, that's been helpful to get me started, cheers

  • Glad that helped.  There are usually many ways to deal with any particular issue in IDM.  Which is fun.

  • I think your and Geoffs solution will work fine.

    The order is predictable.


    I had the same case about 10 years ago and that solution should still be here somewhere.

    Will do a search for it.

    Can't remember the name of the thread but it was the closest call I ever had to catching Father Ramon with being wrong.

    He never was

  • I miss Shon. I see his shenangans on Facebook still though. Father Ramon was the best.

  • He really was.

    Cant find the post though.
  • Verified Answer

    thanks for having a look.  

    turns out the "delete" event is easier to manage than I first thought - at least in my case.  In our openldap directory it's a safe assumption that the usernames are unique - so on a delete I can just query back to LDAP for an object with the same username and if it exists it was a move rather than a delete.  

    just adding that in case anyone stumbles over this in a search in 10 years time! 

  • That was a good solution!

    Thanks for sharing it.