Clarification on Account Correlation During Aggregation

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

Hi All,

Just to provide some context, I configured a source connector (Azure AD in this case) and performed an aggregation. As expected, the accounts were initially brought into SailPoint in an Uncorrelated state.

I then configured the trusted source and ran an aggregation from the UI, expecting the Azure accounts to be automatically correlated. However, even after the trusted source aggregation completed, the Azure accounts remained uncorrelated.

To verify further, I ran another Azure aggregation, but the accounts still did not correlate. The correlation criteria is straightforward and based on UPN, which is identical between the trusted source and Azure accounts.

Given that the correlation key matches, could you please help us understand why the accounts are not being automatically correlated during aggregation?

Interestingly, when I selected an individual account and performed a manual aggregation from the UI, the account was successfully correlated.

This leaves us unclear as to why a full Azure source aggregation is not triggering the same correlation behavior. This is an important scenario for us, as we plan to follow the same process during our production cutover and need confidence that accounts will be correlated automatically.

Could you please share your thoughts on the expected behavior and any recommended approach for handling this scenario?

Thank you for your assistance.

Regards,

2

It seems to be aggregation is running with optimization from UI due to which correlation is not happening. Can you try aggregating the source without optimization from vs code or postman?

image
image516Ă—264 28.5 KB

3

See Loading Account Data - SailPoint Identity Services for the differences in aggregation types

4

Thanks plan is to try via API

https://sailpoint.api.identitynow.com/beta/sources/:sourceId/load-accounts

Does it require flatfile with accounts as in param, can’t we run for all the accounts without specifying flatfile.

am getting error

“causes”: [

    {

        "locale": "en-US",

        "localeOrigin": "DEFAULT",

        "text": "The request does not contain a valid file"

    }

\]

I

5

Thanks for the clarification.

For our returning user use case, the expectation is that the account should be automatically correlated once the trusted source data is aggregated into IdentityNow.

At the moment, it appears that we need to manually run a non-optimized aggregation to achieve the correlation, which is not ideal from an operational perspective. Ideally, when the trusted source data arrives, SailPoint should automatically correlate it with the existing uncorrelated Azure account based on the configured correlation criteria.

Could you please confirm whether this is the expected behavior or if there is an alternative approach that we should be considering?

6

Hi @lalithajay This is expected behaviour. Best practice would be to not delete Identities where there is a re-hire possibility.

7

Apols, re-read the post. This isn’t a re-hire scenario, this is a deployment scenario. As such, running the un-optimized aggregation is best practice.

8

Ah, i see where i got the re-hire from:

In this case, ISC would not delete the Identity while a correlated account exists. See Identity Deleted | SailPoint Developer Community

9

you need to update the content-type. If content type is “multipart/form-data” then you need to upload csv file/flatfile. Instead use the below content type and including form-data: disableOptimization=true in the Body of the call.

below is for your reference to run the unoptimized aggregation via API.

POST /beta/sources/:sourceId/load-accounts HTTP/1.1
Host: sailpoint.api.identitynow.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Authorization: Bearer 
Content-Length: 24

disableOptimization=true
10

there is workflow which is developed by community experts. This workflow you can run unoptimized aggregation. Check below post and hope this will helps for you

11

@vemadeepak Thanks for your feedback and answers, the workflow feature is not on in our tenant, as such looks like I need to run seperate PowerShell program or related to run a non-optimized schedule on this source in different intervals using above sailpont APIs.

so kind of additional overhead as in addition to the scheduled optimized aggregation via sailpont UI have to run another non-optimized outside sailpoint UI.

12

Hi @lalithajay It is my opinion you only need to run the un-optimized aggregation as part of your deployment. On-going re-hires (if the Identity isn’t deleted) should aggregate/correlate correctly.

13

Thanks for your feedback appreciated

Even though there is a compliance need to have one target account even after deprovisioned LCS

Due to large no of inactive records, we decided to have checkDeletedDisabled = false as such when the record goes out from trusted aggregation the identity should be deleted.

We tried this and experienced that target account goes to uncorelated,

but as per your article shared, the identity is not really getting deleted, if so why the target record shows as uncorelated?

Let me know if my understanding is different to yours.

see my other discussion

14

Hi @lalithajay

This (from Loading Account Data - SailPoint Identity Services) implies that the accounts is “treated” as uncorrelated, but is still “attached” to the hidden identity:

When an identity is hidden:

  • Since it is not connected to an identity profile, its last name, email, and UID values are no longer mapped, and the identity does not appear on the Identities page.
  • All accounts previously correlated to the identity remain attached to the hidden identity, but they are treated as uncorrelated accounts since their associated identity is not an authoritative identity. In an uncorrelated accounts certification that includes the accounts’ sources, these accounts will be grouped together under a shared uncorrelated identity.

My understanding is correlation is on the Account object, attachment is on the Identity object. In a re-hire situation, this implies that if the re-hire action triggers a change to the target account (say enabled=true), that would be picked up in the next standard aggregation and correlate the Account.

I should say, I haven’t done a lot of investigation in this area because in my use cases I’ve been able to include a termination offset to match the target Account deletion. ie if AD Account gets deleted at +90 days, then keep aggregating the Auth Source until termination +90 days.

15

Hi @j_place

Thanks for your reply again, I will certainly test this out and let you know if any further issues,

However your answer brings a discussion that with our checkDeletedDisabled=false,

and it is not really deleting the identity (in my case because one target account is still there as we cannot delete it in de-provisioned LCS) but just getting hidden in the UI. Which means still all the hidden identities are vulnerable for daily identity refreshes etc. because it is not a true deletion, so might as then keep with checkDeletedDisabled=true

16

Hi @lalithajay

I would guess it is personal preference. As it sounds like you have a governance reason to keep history of Identities (your persisting target account), I would go with checkDeletedDisabled=true which would also have the benefit of covering your re-hire scenario in a cleaner manner.

You mention on the other post that you have had performance issues with that, though, and if that is a priority then go with checkDeletedDisabled=false (I can’t believe ISC would be doing a full Identity refresh on hidden Identities, my assumption would be that it only checks to detect whether hidden Identities can be fully deleted).

You would also want to consider licensing implications of checkDeletedDisabled=true.

17

Hi @j_place

Confirming what you commented prior, Even with checkDeletedDisabled=false for rehire usecase it is smooth and no issues, after the source aggreation, previous uncorelated account corelated with the identity without any manual interventions.

18

Thanks @lalithajay Are you all sorted then? BTW, Visual Studio Code plug-in provides a UI for un-optimized aggregation.

19

@j_place

My original issue still remains unresolved.

Based on the responses above, it appears that performing an unoptimized aggregation may be required. However, what confuses me most is the difference in behaviour between the two sources.

For our on-prem AD source, newly created accounts are aggregated and correlated automatically without any manual intervention as soon as the account trusted source account/identity is available. In contrast, Azure accounts do not appear to follow the same behaviour.

The correlation logic itself is very simple and straightforward. If I manually run an aggregation against an uncorrelated Azure account, the account correlates successfully, which suggests there is no issue with the correlation criteria.

I am therefore curious whether this is a known behaviour specific to Azure accounts. Has anyone experienced a similar issue where uncorrelated Azure accounts do not automatically correlate, while on-prem AD accounts correlate without any intervention?

Any insights would be appreciated.

Thanks.

20

Hi @lalithajay As i mention above, a modify of the account (say enabled=true) needs to be triggered for aggregation to pick up the change. I assume you are modifying the AD account in some way, but maybe not the Entra account? Are you using Entra Sync? Does the update to the AD Account trigger an update to the Entra account? Are you waiting for Entra Sync to do its thing?