kend82 Valued Contributor.
Valued Contributor.
182 views

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

Jump to solution

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?

 

Labels (1)
0 Likes
1 Solution

Accepted Solutions
kend82 Valued Contributor.
Valued Contributor.

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

Jump to solution

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! 

0 Likes
8 Replies
Knowledge Partner
Knowledge Partner

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

Jump to solution

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.

kend82 Valued Contributor.
Valued Contributor.

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

Jump to solution

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 🙂

0 Likes
Knowledge Partner
Knowledge Partner

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

Jump to solution

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

0 Likes
Knowledge Partner
Knowledge Partner

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

Jump to solution

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 🙂

0 Likes
Knowledge Partner
Knowledge Partner

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

Jump to solution

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

0 Likes
Knowledge Partner
Knowledge Partner

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

Jump to solution
He really was.

Cant find the post though.
0 Likes
kend82 Valued Contributor.
Valued Contributor.

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

Jump to solution

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! 

0 Likes
Knowledge Partner
Knowledge Partner

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

Jump to solution

That was a good solution!

Thanks for sharing it.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.