AD Account Creation Failures – Timeout, Certificate Issues, and VA Availability

[jared-fox]

Overview:

On the evening of June 16, SailPoint failed to provision Active Directory (AD) accounts for four newly hired users. The failures were split into two distinct error types:

1. Two users encountered the following error:

“Unable to generate a unique value for ‘User1’, action UniqueAccountIdValidator[…] is not retry-able due to InterruptedException: Timeout waiting for response to message […] after 30 seconds.”

2. Two other users encountered this error:

“Failed to connect to IQService. Please check TLS configuration for IQService: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.”

Things to Note:

• Several dozen other users provisioned successfully during the same batch.

• Manual reprocessing of the four failed identities succeeded immediately.

• One SailPoint Virtual Appliance (VA) was down due to a missing root certificate, and the other was pending an upgrade at the time of the failures.

• The TLS-related error was resolved the next day by installing the required root certificate on the affected VA.

Our Analysis (And Questions):

• The UniqueAccountIdValidator timeout error occurs when SailPoint attempts to validate that a new account’s nativeIdentity (e.g., CN or sAMAccountName) is unique in the target system—Active Directory in this case. I assume, based on the error given, this validation step requires a timely response from the AD connector via the VA. If the VA is unresponsive or overloaded, the validator times out and the provisioning step is marked as non-retryable, requiring manual intervention.

• Is this behavior consistent with known SailPoint provisioning patterns where infrastructure latency or connector unavailability can cause failures that are not automatically retried?
• Has anyone heard of or experienced something similar?

• The TLS certificate error (PKIX path building failed) directly points to a missing or untrusted root certificate on the VA. This prevented secure communication with IQService, which is required for provisioning AD accounts. Once the certificate was installed, the issue was resolved.

Evidence:

User 1 and 2 Error:

[“Failed to connect to IQService. Please check TLS configuration for IQService: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target”]

This error is related to our VA01 not having the root CA installed at the time.

User 3 and 4 Error:

“Unable to generate a unique value for ‘User 3’, action UniqueAccountIdValidator[nativeIdentity=CN=User 3s Name,OU=_New Users,OU=Users,OU=OAC,DC=corp,DC=theoceanac,DC=com,app=Corp.theoceanac.com AD] is not retry-able due to InterruptedException: Timeout waiting for response to message 0 from client ad4b2439-7733-49e1-9e03-a672efda54fe after 30 seconds.”

While an easy solution was found in simple reprocessing the identities, I want to know if this is simply related to the state of the Virtual Appliances at the time, or if it’s something I should worry about happening with future new hires. We tend to hire in large batches and catching these occurences may prove difficult.

[udayputta]

hi, The first error that you mentioned it could cause when two or more users have same first, last names. I am going with the assumption that you have used them to calculate your sAMAccountNames. When SailPoint trying to create AD accounts in bulk and when two different users get same names then SailPoint will create account for one user successfully. For the other user it would have used same sAMAccountName and it would have failed because during that time SailPoint does not know if the value is taken by other user. If you have the birthright role then in the next event processing SailPoint should create the account for the failed users. Yes there will be a delay if you do not want to wait for that you may create a workflow for the failed users and trigger processing for the user by adding some delay.

The TLS problem would be something due to the version upgrade. Make sure you are using AD source with TLS enabled and having the cert installed. Or else you will start seeing that again.

[jared-fox]

Hey @udayputta, thanks for your response. In this case, none of the users had the same name, so I don’t think that was the issue. I’m leaning toward the degraded performance of our VAs being the root cause—one was down and the other pending an update at the time.

Could that have led to a slowdown in the UniqueAccountIdValidator process, resulting in a timeout error that was marked as non-retryable? That seems like the most likely explanation, especially considering how many accounts processed successfully overall, and the fact that the affected accounts went through without issue when I processed them manually later.