Native Identity should not be null or empty

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

When a user get terminated and re-hire or when the OU movement happens and user comeback to the same OU 2 AD accounts get mapped to the same user. It doesn’t get created in AD, only shows up in SP Identity. This creates trouble for the users when requesting access or adding entitlements. Seen a similar discussion below, but no resolution reported. Anyone with the same issue can provide some inputs on how to resolve this issue.

2

Hi Ravi,
Are you aggregating both the OU for which user was moved ? So if the users was in Enable OU and then moved to Disabled OU…are you aggregating both the OU’s?

3

Yes Rakesh. I am aggregating both the OU’s.

4

Hi Ravi,
The issue is most probably because Access Profiles are never refreshed by Sailpoint only roles are refresh. Can you try to refresh the user and see if the old Application gets removed?

Thank

5

I have tried that as well. no changes. The issue is with the same user account appears twice for the same source.

6

Hi @RaviPalanisamy , we are facing the same problem? Did you manage to find a solution?

7

It’s just because you have kept deletion threshold too low or disabled deletion altogether. The old OU account stays there even if it is not found from aggregation because of low threshold

8

No Solution yet on this! We have it at 9% which is in the higher side already. Deletion is not disabled on AD source.

9

This could be a bug. We have had similar situation as well, where multiple AD accounts were tagged to the same user (who had an OU movement), whereas only a single account exist in AD.

We had to manually remove one account from the UI (remove account action) to get this fixed.

Raised a support ticket (CS0274353), but did not receive any meaningful response.

@jordan_violet @colin_mckibben

10

We encountered a similar issue where we utilized the “Services Standard Before Provisioning Rule” to move accounts to a different OU during enable/disable operations. While the accounts were successfully moved to the designated OU, we noticed that after approximately 10-15 minutes, the ISC automatically re-added the old account (as indicated by the “ADDED ACCOUNT” event in the event timeline in Access History). We raised a support ticket and were informed that this issue might be related to the rule. They recommended making an expert services case, which we didn’t. Instead, we ended by aggregating the AD source 30 minutes after aggregating the HR source, which deleted the auto-added old account.