SailPoint ISC LDAP Connector Timeout causing Duplicate AD account issues

Administration & Troubleshooting
,
1

We encountered duplicate Active Directory account creation in SailPoint Identity Security Cloud (ISC) under the following conditions:

  • The AD account was successfully created by the connector.

  • ISC did not receive the success response within the default 180-second timeout, resulting in:

    • java.lang.InterruptedException
    • The provisioning event marked as Failed

  • Because ISC assumed the create operation failed, it automatically retried the create request ~14 seconds later.

  • The retry resulted in a second AD account being created for the same identity.

  • The “NA” entry in the Network ID History table occurred because the timeout prevented ISC from capturing the created account name from the connector response.

Any ideas on how to remediate this issue? Obviously continuing to increase the timeout is not best practice. Thanks.

2

As mentioned in the post, we have our timeout set to 180 seconds currently - is there any logic I can add to perform some sort of lookup for the intended account to see if it exists after a Failed Event? The event will only be re-tried if the lookup comes back as the account not being found..

or just some sort of post-failure retry verification so it doesn’t automatically retry and continuously create dupes.

3

Hello @colsmith, is this native AD connector behavior - or are you using any type of a rule? If native, perhpas you may want to open a Customer Support ticket - if you haven’t already?

4

Hi @colsmith the most common reason for duplicate account creation is when aggregation overlaps with an identity refresh event.

Scheduled identity processing occurs twice daily, at 8:00 AM and 8:00 PM in the tenant’s configured time zone (default CST/CDT). But identity processing also occurs when someone clicks “Apply Changes,” for example.

Here are some questions to help guide further troubleshooting:

  1. What time(s) of day does AD aggregation occur?
  2. What time stamp does a FAILED provisioning event have?
  3. Does this issue occur upon EVERY AD aggregation or at certain times/dates?
  4. If you schedule AD aggregation at a different time of day, does this issue still occur?
  5. Does this happen with EVERY AD account creation event OR have you narrowed it to a specific account creation from certain
    1. access profiles?
    2. roles?
    3. lifecycle events?
    4. or during OU moves?

Here are some resources to guide you as well:

If you need assistance deleting duplicate accounts, SailPoint Support can assist with this.

Regarding your follow-up question on custom logic, I will reply directly to that post.

5

Q: is there any logic I can add to perform some sort of lookup for the intended account to see if it exists after a Failed Event? or just some sort of post-failure retry verification so it doesn’t automatically retry and continuously create dupes.

My response: The AD connector has configurable retry options for provisioning failures. Have you configured these, as per the connector guide?

Beyond that, understanding the root cause of the java.lang.InterruptedException  may still be a key step.

  • As Paul inquired: are there any AD connector Before Creation rules in place?
  • Do you have an internal firewall rule that could be blocking communication between the Virtual Appliance and the AD source?
  • Do any authoritative source identity attributes get values from AD accounts? And do any of those have transforms applied to them that could potentially cause some kind of race condition?

Additional resources for further debugging:

I hope one of these suggestions leads you to the final solution. Please let us know what works for you or what additional information may help us make further suggestions..