Account provisioning to AD is failing

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Active directory provisioning failing with the following error “Unable to generate a unique value for '', action LDAPUniqueValueValidator[proxyAddresses="",app=AD - ] is not retry-able due to InterruptedException: Timeout waiting for response to message 368 from client 31d25113--4369-b080-**** after 30 seconds.”

We have cloud rule in place which checks for uniqueness for mail and proxyaddress before it creates the account in AD.

We have increased the provisioningTimeout to 300 seconds for active directory source. This didn’t help. We are aggregating Ultipro source from HR. All new accounts are failing.

Any help is appreciated.

2

The timeout is indeed happening waiting for the uniqueness check. Can you give us the code to your cloud rule?

3

proxyaddresses is a multi valued attribute in AD. What are you passing to check uniqueness? How are you generating proxyaddresses?

4

if (idn.isUniqueLDAPValue(identity.getName(), application.getName(), “mail”, email) && idn.isUniqueLDAPValue(identity.getName(),application.getName(),“proxyAddresses”,proxyAddressSearch))

                                            {

                                            log.error("Email Attribute Generator: Check Uniqueness: returning true");



                                            return true;

                                            }
5

We are passing FN and LN and the rule generate the email and checks AD for uniqueness

6

Initially it was checking for mail attribute. It was working fine. As soon as we updated the rule to include checking for proxyaddresses as well, it started failing

7

Are you prefixing the proxyaddress with “smtp:”? How are you generating proxyAddressSearch?

8

Not sure if it’s the code or resources in AD is the issue.

9

Hello,

Can you try to use non-indexed Search attribute in SailPoint ISC to perform the uniqueness check? Using “isUniqueLDAPValue“ is also a good option but it will depend upon the LDAP connectivity as well.

Refer the below article where this uniqueness check is performed inside Account Attribute Generator Rule only but with a different API/Method.

10

I doubt its resources in AD and increasing time out won’t help here. The values within proxyaddresses are indexed so that Exchange can perform a rapid recipient lookup.

11

Hi @ashok77b ,

isUniqueLDAPValue method will not work for checking the uniqueness of the proxyAddresses attribute since it’s a multi valued attributed instead you need to make use of the below method

public int attrSearchCountAccounts(List sourceIds, String attributeName, String operation, List values)

Below is the implementation for your reference

image
image1096×416 25.5 KB

To achieve this you need to create a new search attribute Using IdnRuleUtil as a wrapper for common Rule operations | SailPoint Developer Community and run the account aggregation by disabling the optimization.

I hope this helps.

Thanks!

12

Hi @dineshdupati Are you sure you can’t use isUniqueLDAPValue to query multi valued attributes? I can see no reason in the LDAP spec why that would be the case?

13

could there be issue with the VA or IQservice ? The same code works in our sandbox environment. In our production, it worked for initial few days. It was failing for 20% of new accounts and we increased the timeout gradually. But, now a days we see 100% failures.

14

If it is a problem with servers, it will be the VA rather than the IQ as I believe IQ would not get involved in an LDAP call.

1 Like
15

Also, is this a multi-domain forest?

16

Yes. Parent and has a child domain.

17

Perhaps check the forest settings on the connector. I’m afk at the moment, but I’m wondering whether it’s a GC vs DC thing.

18

There was a DNS resolution issue with the VA. We have fixed the DNS issue and the provisioning issue has been resolved. Thank you all very much for your helpful tips to resolve my issue.

19

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.