Please share any other relevant files that may be required (for example, logs).
[Please insert files here, otherwise delete this section]
Share all details about your problem, including any error messages you may have received.
Hi everyone,
We are troubleshooting a performance issue in SailPoint IdentityIQ 8.3p2 with an application using the LDAP Connector.
The issue occurs only when selecting roles in an access request. After clicking the checkbox to select a role, it takes approximately 3–4 minutes just for the checkbox selection to complete. The issue is not observed in lower environment.
The checkbox-based role selection is part of the SailPoint IdentityIQ functionality of the target application.
Could anyone suggest what could cause such a delay specifically during role selection and how we can determine whether the delay is related to LDAP calls, the connector, or IdentityIQ processing?
Any suggestions on debugging steps would be appreciated.
Enable logging for sailpoint.connector.LDAPConnector and sailpoint.api.Provisioner within log4j2, check the box just once, and look at the timestamps if the delay of many minutes is between an LDAP search/bind request and its answer, it is in the directory.
Perform the exact same search query outside IIQ. If the selector rule/form for this role uses a particular LDAP filter to perform its search, perform the search directly using ldapsearch (or the IQService test connection) to the same DC. If it is slow without IIQ, the problem is not IIQ but the network path.
Verify whether the actual DC/URL prod that is hitting within the application definition is a Single Named DC or Load Balanced, because it will only impact prod if it is Stale/Down.
Do a thread dump (jstack of the Tomcat PID) when the check box freezes. If you see any thread waiting in javax.naming.ldap.* or com.sun.jndi.ldap.*, it is LDAP I/O that is consuming the time and not IIQ.
Switch off the rule or the provisioning form of the role, either in the Account Selector Rule or the provisioning form (this being a safe environment), then try again. The instant the box becomes active, you know for sure that it is the trigger.
If possible share the logs to understand the pattern.
every time you select a role in the manager user access, IIQ check if the role is already assigned and if the role has a form, the code in the form will be executed.
The reason could be on the identity, id the the identity have a lot or roles or into the code, if the code is not good.
@aashishsingh1 There are already great suggestions by the other fellow Sailors. I would like to add a few more areas worth checking:
Since this only happens in Production, check how many assignments the selected user has. build things in a sandbox — onboard apps, create workflows, run certifications, break things and fix them.
If the role has a provisioning form or population filter or an Account Selector Rule that queries LDAP or the IIQ database or any other external system to determine eligible accounts, that code runs on every checkbox click. In production with a larger dataset, these filters can be dramatically slower.
Capture GC logs from the application server during the freeze. If the JVM is under memory pressure in prod (larger heap usage, more concurrent users), long GC pauses can manifest as UI freezes. Check your -Xmx settings and GC algorithm configuration.
You might want to rule out each item one by one to know exactly what the issue could be.
Thread dump during the freeze → tells you if it’s LDAP I/O, DB wait, or rule execution
Test with a lightweight identity (few roles/entitlements) → tells you if identity size matters
Disable the Account Selector Rule / provisioning form temporarily → tells you if form logic is the culprit.
Hope this helps narrow it down! Let us know what you find.