Duplicate Account Creation in AD Source

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

Hi All,

We are in the final stages prior to go-live and detected a strange issue which appears to be due to the processing order when aggregating accounts from the HR source.

We currently have some basic birthright roles created that trigger account creation in our AD source, however what we are experiencing is that when a record is aggregated from the HR source and there is an existing AD account for the user (With the employee number in the correct attribute), rather than correlating the existing account to the identity the role is assigned triggering a new “Duplicate” account to be created in AD.

The new account is not a true duplicate as all the unique generators work as expected however the attribute we use for the employee number (and included in the correlation logic of the AD source) is duplicated, thus the manager receives a notification that a new account has been provisioned and is ready for use.

The AD source has many records that historically were created manually and there is a separate project underway to onboard these accounts to the HR source and ultimately have these managed through ISC, however creating “duplicates” and cleaning them up would not be sustainable.

Is there a supported method to delay the role provisioning till both the HR source and AD source have completed aggregating to allow sufficient time for the correlation logic to process?

2

Hi @Bobbo_za , I would have first aggregated the accounts from AD source and correlate them to respective identities. Make sure all the accounts are correlated and then only enable the AD roles so that duplicate account creation would have been stopped. Is it not possible to disable the roles for now?

3

You’re right, this will be followed when we bring on new sources or extend the scope of the existing source (Additional Legal Entities etc), however we have many cases where through many years of technical debt, AD accounts already exist but no record exists in the HR source, thus once this is identified the HR team are then requested to go through the process of onboarding the Person details, this then aggregates to ISC and creates the Identity but also then creates the AD account before the Correlation from AD could happen, effectively duplicating the account.

4

Sounds like you might need to create identities in a “pending” lifecycle state (or something similar) which allows the identities to be created and correlation to occur. without provisioning. Then update the lifecycle state to “active” and have roles assigned based on that. Off the top of my head, the logic could look something like:

{
    "type": "static",
    "attributes": {
        "CalculatedState":{
            "attributes":{
                "id":"Your Lifecycle State Calculate Transform Here`"
            },
            "type":"reference"
        },
        "CurrentState":{
            "attributes":{
                "ignoreErrors":true,
                "values":[
                    "$oldValue",
                    "NEW"
                ]
            },
            "type":"firstValid"
        },
        "value": "#if($CurrentState == \"NEW\")pending#{else}CalculatedState#{end}"
    },
    "name": "Lifecycle State Check"
}
5

We logged a request with our CSM and the Dev team enabled the following flag on our Sandbox tenant, so far the testing has been positive: GOV_ARSENAL_21056_SKIP_CREATE_ACCOUNT_REQUEST_ON_IDENTITY_REFRESH

Although we do still have a different use case for the pending LCS we will most likely still use this but primarily not to avoid the duplicate accounts being created.

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.