We have multiple LDAP connectors in our environment. Recently, we added a new application that uses one of these LDAP connectors.
When we make updates to the link through any type of provisioning, the target is updated successfully. However, the link on the IdentityIQ side is not updated (even after running the Perform Identity Request Maintenance task) until an account aggregation is performed to pull those updates.
Has anyone else observed this issue? It occurs only with this particular LDAP application; none of the other LDAP/AD applications experience this problem.
Please let me know if you need any more information.
Thank you.
what is the status of the access request in IIQ - after submitting the transaction and after PIRM task? Is the provisioning transaction also successful and completed?
Are you using AD or LDAP connector for the application in question as they are different ?
when you say link at the IIq side is not updated, meaning what?? post provisioning, you can’t see any link?? can you just show with the use case for better understanding.
Let me give a brief regarding the scenario, Lets say LDAP link created for a user from EIM then we are running attribute sync(In short we are sending a modify request from EIM) then the provisioning completes and provisioning transaction says committed and is successful but the value is not updated on the link(in EIM) but was provisioned successfully. Until unless we aggregate the account we dont see the changes on EIM
You mentioned that this is happening to specific LDAP application and not all. Any thing different for this application?
Is it happening for any specific attribute like entitlement - is the schema for that attribute correct and matching with other working LDAP application.
Yes, we have 2 other LDAP applications configured and at least SailPoint configuration wise there is no difference as such in this and the other ones.
The schema is correct and we even tried matching data types with the ones in the target application but that did not result in any changes to the behavior.
Suggestion - you can add one more step at last which performs single account aggregation before the workflow is actually complete. you should be able to find script in sailpoint compass for single account aggregation for LDAP apps.
thats global configuration which should be used for other LDAP application as well without this additional step. right?
If this is issue with specific application where it doesnt work only for one application while it works for other application of same type, the issue must be with application config only and not some global config.
For the impacted application, are you using any load balancer which might have multiple LDAP backend. Its might be possible that when the provisioning transaction is sent from SailPoint , its sent to one of the backend LDAP while the immediate read is happening from other LDAP which is not synced yet with LDAP that was modified.