We only provision accounts to AD, and then AADC synchronizes them to Entra ID/Azure. SailPoint itself only updates a limited set of attributes in Azure via attribute sync.
In this scenario (for example, during a cutover), both the AD account and the Azure account initially exist in an uncorrelated state. Both accounts are aggregated into SailPoint through their respective AD and Azure aggregations.
When a source-trusted aggregation occurs, the AD account is immediately correlated to the identity, even before any scheduled AD aggregation runs. However, at this stage, AD is not configured as an account source within the Lifecycle State (LCS). This makes me wonder whether an uncorrelated account can still be correlated and attached to an identity solely based on successful correlation logic, regardless of any Identity Profile account source conditions.
The uncorrelated Azure account, however, does not get correlated in the same way. My assumption is that this may be because SailPoint is the provisioning source for the AD account, whereas the Azure account is created and managed through AADC synchronization. This is essentially the key difference between the two sources: SailPoint provisions the AD account directly, but it does not provision the Azure account (it only synchronizes a few attributes).
Hopefully this provides some useful background and context.
Can I just clarify - are we still talking about the re-hire situation?
During deployment of a new Auth Source, un-optimized aggregation of connected sources is needed. During optimized aggregation, correlation is only attempted if the information that is aggregated (Account schema) from the Source has changed in some way.
Doing a single manual aggregation does not require the data in the source to have changed.
As to whether AD is treated differently, it sounds like you are updating AD in some way from ISC, so that will trigger correlation. If the data in Entra has not changed it will not get re-correlated.
Under the main topic of Account Correlation During Aggregation, the Rehire scenario is clear now. In our case, there was a hidden identity, and the correlation worked as expected without any issues and tested.
My question relates to the other aspect of Correlation During Aggregation, specifically from a deployment and cutover perspective.
In this scenario, both AD and Azure aggregations are configured and running, but all accounts remain uncorrelated because the Trusted Source data has not yet been aggregated. I simulated this situation, and my question is based on the observed behaviour.
The key point is that I am not referring to the target source aggregations themselves. Rather, when I performed the Trusted Source aggregation, the AD account was immediately correlated to the identity, whereas the Azure account was not. This occurred even before any AD aggregation had been executed.
From your response, I understand that you are describing behaviour related to target source aggregations. However, the scenario I am referring to is slightly different, as the correlation occurred during the Trusted Source aggregation process.
Another important distinction is that the Azure accounts are not provisioned by SailPoint. AD accounts are provisioned directly by SailPoint, while Azure accounts are created through AADC synchronization, with SailPoint only synchronizing a limited set of attributes. I am wondering whether this difference could explain why the AD account was automatically correlated while the Azure account remained uncorrelated.
Hi @lalithajay The only reason I could potentially see for the AD accounts getting automatically correlated is that you are re-running a test without completely purging the Identity data (ie there were hidden Identities prior to the Auth Source aggregation). I don’t know of any mechanism that would automatically correlate AD accounts for a new Identity (not saying that there isn’t, but you’ve hit the limit of my knowledge).
Hi @j_place thanks, this use is not rehire hence no hidden Identity,
This is all about automatic correlation of AD account (which was in uncorelated state, fetched from priror AD aggregation ) for a brand new identity created during trusted source reconciliation.
Yes, the issue is not AD aggregation issue, as explained above
uncorelated AD account get corelated automatically when Identity is created but not the Azure account, it still remain as uncorelated eventhough corelation criteria is met.
before running any unoptimized against Azure source, just trying to get same behavior like AD for Azure as well.