Identities not Correlating before Creating Accounts

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

Hello,

I’ve been struggling with duplicate accounts being created into Active Directory because SailPoint is not attempting to correlate existing uncorrelated accounts before running the Create Account process.

The HRIS (Authoritative Source) is UKG Pro Core HCM and this has become an issue (we recently went live) with contractor conversions and when we manually create an FTE ahead of time.

  1. Contractor Conversions - I have gone into AD and added the FTE employee number to the contractor AD object (this is our main correlation attribute), manually aggregated AD, and then confirmed the EID shows up on the account in SailPoint. However, when UKG aggregates it is running the Create Account process against AD instead of first trying to match up to any uncorrelated accounts. I know the correlation works though because if I manually trigger an account aggregation on the uncorrelated AD account (an unoptimized aggregation I believe it’s called), it will connect it up to the identity - which at that point has 2 AD accounts correlated to it.
  2. Manually Creating FTEs - We have a bit of a predicament where UKG stages new hires in a separate module that we do not (yet) have access to via API. Our HR team doesn’t move them over to the main module until the night before they start. So currently we are manually creating the AD account ahead of time in order to setup the laptop. However, we’re dealing with the same issue here. We do not yet have the EID, but our secondary correlation is the email address which is correct. When UKG creates the Identity the night before, it is creating a duplicate AD account instead of running a correlation first. Again, I know the correlation works because if I manually trigger an aggregation on just the uncorrelated AD account it will correlate it to the Identity which then has 2 AD Accounts correlated to it.

Has anyone else dealt with this before? Is there a way to force SailPoint to fully attempt to correlate before running the creation process? Even if I wanted to manually run unoptimized aggregations to connect the account, I can’t do this until after UKG creates an Identity, and it is instantaneously running the Create Account against AD and generating a duplicate account. These duplicate accounts are messy, a security concern, and an audit concern and I would like to automate them away.

TLDR: Why doesn’t SailPoint ISC run a full unoptimized aggregation to correlate uncorrelated accounts BEFORE running any Create Account processes?

2

Hi @matthew-newton,

I am thinking you have a Birthright Role configured and it is triggering the Provisioning of the addition account for Active Directory. What you can do is as below.

  1. Disable the Role.

  2. Let the identity create from Sailpoint.

  3. Have a trigger for Workflow for Identity Created.

  4. After the Identity is Created check if you have the account in the uncorrelated Account in Active Directory source.

  5. If you find it you can correlate them to the current identity using the Account Patch api.

  6. If not found you can have raise a request for Access Profile which will give access to the Active Directory Account.

    Let us know if you need any more details on the same.

3

Working with Ask an Architect it appears that the solution has to be creating a “Before Provision” Cloud Rule that checks if an account already exists, correlates manually, and changes the Plan to a Modify for that one instance so that it doesn’t run the Create process.

I hope to get this configured and then provide my Cloud Rule solution here. However I am running into issues setting up the RDK with Java and Maven - getting an error:

[ERROR] ProvisioningTest.testProvisioning:31 Mockito
Mockito cannot mock this class: class sailpoint.object.ProvisioningPlan.

Trying to work through this issue before I can develop the rule.

4

How would you check if the account exists in the before provisioning rule? I’d be surprised if SailPoint allows you to create a connector instance or direct LDAP context in a before provisioning rule since it’s a cloud rule.

The hacky method is to map a lifecycle state for a new/rehire identity called something like ‘pending’ and then leave them there for X amount of hours and then build a scheduled workflow that triggers an unoptimized aggregation every couple of hours or so to pull in accounts that should correlate BEFORE roles are assigned in a pre hire/active lifecycle state. (They don’t let you do this via normal configuration, so has to be done via the workflow/API). Also it has to be unoptimized because the account is technically already sitting on an uncorrelated identity and won’t move over during a normal optimized aggregation (unless something changes on that account).

5

We correlate off the EID and can get that into AD and run an AD aggregation ahead of time, usually. So SailPoint would only need to look at the AD Source for any Accounts that have that EID in that attribute.