AD Deprovisioning intermittent fault

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

Hi,
I’m getting an intermittent fault when trying to disable accounts. It only affects the one AD account - none of the other of which there are many, and are all built the same.
Has anyone seen this before? (single account aggregation and source account both work, and the account is where it says it is, so not option b or c, but also if it can aggregate then its not a either).
Basically it works on any where between t he 1st and 5th attempt at disabling

["Error(s) reported back from the IQService - Error occurred while disabling the account ***
Failed to connect to the server for CN\u003dA******net:
There is no such object on the server. 0000208D: NameErr: DSID-03100245, problem 2001 (NO_OBJECT), data 0, best match of: \t\u00***** . 
HRESULT:[0x80072030] Possible reasons for failure include 
a) The Domain Controller is currently not reachable 
b) The object has either been moved or renamed 
c) The object has been deleted \n 
Please Ensure the data has been aggregated before performing the operation "]
2

I’m going on the assumption here that you have 1-x IQ Service servers and 1-x DC’s

You should ensure that there is good connectivity between any of the IQ Service servers and all of the DC’s in your network.

3

Its just the deprovisioning that its intermittently failing on, and only on the one source

An no, we are running 1*IQ server to multiple ADs at the moment. And they all work fine

4

This issue majorly occurs when you have a load balancer in place either for DC or IQServices. I would check whether all the DC nodes sync with latest data and also check the connectivity.

5

There is a load balancer in place for this source, however, the error message still pops up when I switch it over to a single server.
I’ll raise a ticket to check the DC node syncing. Thanks

1 Like
6

Please check the AD connecters & IQS certificates are latest and matching with your source configuration. For example, The DN name should be same with case sensitive between the source config and in the certificates.

7

Even I was seeing this problem and it does not happen every time. Do you also have a OU movement logic when disabling the account? We have single IQ service server with multiple DCs. We do not have a load balancer. IQ Service server is up to date. I will validate the cert once.

1 Like
8

We are using AC_New_Parent to move it in and out of the disabled OU.

9

Then there is your clue I guess. Since ISC doesn’t yet update the DN when you move an AD account to a different OU using AC_New_Parent, it needs to be aggregated before it can be updated again.

10

ISC performs a single account aggregation as part of either the enable or disable provisioning policies, and updates the DN on the identity cube. That is not the issue

11

Hi @phil_awlings Got any special characters in the CN?

12

Hi @j_place ,
No it doesn’t.
Observationally, it appears that the load balancer is being too efficient and that’s its splitting the instruction from sailpoint (1 - the disable and move OU; 2 - single account aggregation from new DN) to two different DCs which is causing the problem. This was further observed when checking on the DC that the move had happened, but apparently failed according to sailpoint. Alternate single account aggregations switched between passing and failing depending on which DC the API call was sent to.

I’ve removed the load balancer from the Domain settings page on the source, and instead pointing it at a single server. This appears to have solved the issue, but I will keep the source under observation for a while.

Thanks for all your inputs

1 Like
13

Ah, I was going to mention load balancing (see New "AC_NewName" & "AC_NewParent" not aggregating back to ISC - #15 by neeraj99), but you mentioned that it still happened with a single server

1 Like
14

Glad that you find out the root cause. As I said earlier, it will be mostly due to load balancer and you can validate it by using one DC at at time.

15

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