Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Can you cite the source documentation for this answer?
Correlation Rules on one Source would not correlate accounts on another source.
Since the system does not do correlation of accounts until aggregation, you may need to use a Before Provisioning rule for AD to check if the account exists in the connected AD when a Create operation occurs, and if it does, either cancel the Create operation, or change it to an Update/Modify operation for the user. Then when the account is aggregated back in, it will be correlated to the new user.
Hang on, how exactly would this work?
Like I could see how you could theoretically search for accounts in the AD source using Workday attribute values to see if there is an existing AD account, but you’re still only living within the scope of the correlation rule, meaning the output is intended to correlate a workday account to an identity. It wouldn’t be able to correlate an AD account to that identity because the aggregation is happening on the Workday source.
I’d love for you to be right about this as this is a use case that happens a lot, but I’m a bit skeptical.
Right, the correlation rule only has access to the current aggregated account ResourceObject and Application and returns a list of the attribute to check and the calculated value to use with the check. There would be no way to write back to the identity any values from AD. Additionally, I don’t think you could look up the connection information, so you would need to hard code the AD connection details if it was possible.
Currently how we’re handling this, we’ve implemented a staging lifecycle state that is not included in any roles, a workflow is triggered on identity creation that performs the checks and correlates the account if found and then returns the identity back to the standard Lifecycle state based on the Transform that calculates the prehire / active / terminated states.
The testing has been positive from one of our sources and has been implemented into production, we are working on extending the similar functions to our remaining sources.
Hi
as other fellow sailors has suggested. ISC won’t correlate other accounts just by running Workday source aggregation.
Having said that I would like to understand that why the account is uncorrelated in the first place if it belongs to that user?
I think you must fix your existing correlation logic for that application to make sure those accounts stay correlated to the identity so you won’t have to deal with such situations later
In a rehire scenario, the identity is removed from Sailpoint ISC 15 days after termination, according to the current logic in our tenant. Thats the reason AD account is in uncorrelated state.
IMHO, that’s what you should look at. Align your Identity delete with what is happening in AD. From a governance perspective, it’s always best to keep an Identity around while there is an AD account, so you can see the history.
I agree with @pradeep1602 because while identity terminated that time your AD account is already correlated and went to disable state. while your rehire(lifecycle state) trigger that needs to just enable AD account.
As long as my memory serves we can’t delete identities in ISC right?