If I change the native identity of an AccountRequest, does ISC lose the link?

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

Hello guys,

I have an example of an AccountRequest and a question: if I change the native identity via a rule, does ISC lose the link with the account?

I tried several approaches to solve an activity here, but in all tests the account ends up being lost in ISC.

For example, in this scenario:

In this case, during the account creation in AD, the nativeIdentity would be:

CN=henrique alves de oliveira,OU=Users,DC=company,DC=local

If I change this value via a rule and return the request, AD successfully creates the account with the modified value. However, ISC does not maintain the link with the created account. The account ends up being lost, and in some cases the system starts correlating other accounts to this user.

The main issue appears in the following scenario:

Imagine that two employees join the company with exactly the same name.

Identity 1

Name: Henrique Alves de Oliveira

In AD it would be:

DN:
CN=Henrique Alves de Oliveira,OU=Employees,DC=company,DC=local

sAMAccountName:
henrique.oliveira

UPN:
henrique.oliveira@company.local

Identity 2

Name: Henrique Alves de Oliveira

In AD it would be:

DN:
CN=Henrique Alves de Oliveira,OU=Employees,DC=company,DC=local

sAMAccountName:
holiveira

UPN:
holiveira@company.local

The problem occurs because if both accounts are created in the same OU, the DN becomes identical, which causes a duplication error. Since the DN is the native identity in the AD schema, I tried modifying it via a rule.

The change works and the account is created correctly in AD, but SailPoint loses the reference to the second identity and ends up linking the first identity’s account to the second identity, which creates inconsistencies.

So when two people with the same first and last name are created in the same OU, a DN duplication error occurs. I tried several ways to adjust this via rule, but ISC seems to lose track of the account during correlation.

Has anyone experienced something similar or has any recommendation for handling this type of scenario?

2

What rule are you using to change the name and is the name being changed on the request, or directly in AD?

What is your Correlation Logic looking at? Does it look at other attributes besides DN, such as sAMAccountName?

Is the DN being set as an IdentityAttribute or calculated during provisioning?

I would expect that if the correlation is configured correctly, and the account is actually created in AD that it would link up properly and not be “lost”. Seeing as how it can be correlated to the wrong account makes me think that the account correlation needs work to make sure it goes to the right account.

Consider that if you remove SailPoint from the equation: If both accounts were created manually in AD, if both of them correlate to the second account, then the correlation logic is incorrect ot not sufficient.

You still may be able to handle it better for the account request, but we’d need more information about where the values are being calculated/modified.

3

Hello,

What rule are you using to change the name and is the name being changed on the request, or directly in AD?

R:I am using a Before Rule (Create). It takes the original request coming from the Request Center, performs the validations, and returns the sAMAccountName so that ISC can create the account.

What is your Correlation Logic looking at? Does it look at other attributes besides DN, such as sAMAccountName?

Yes, the rule considers the employee number, which is unique for each user. With this, ISC is able to identify the account that was created. However, for some reason, it ends up linking a different account.

Is the DN being set as an IdentityAttribute or calculated during provisioning?

The DN is calculated through a transform in create account/provisioning police.

In this case, I noticed in the IQService logs that after the account create request, it sends a modify right afterward. However, this modify request has a different native identity than the create request, and because of that, the second identity ends up being linked to the first account — at least that’s what I understood.

4

Hi @henriqueoliveira2026

The issue you are seeing usually happens because ISC tracks the account using the nativeIdentity returned during provisioning. If the nativeIdentity changes between the Create and Modify operations, ISC may not correctly match the account that was created.

In your scenario:

The Create request is sent with one DN (nativeIdentity).

After the account is created, a Modify request is triggered with a different DN.

Because the nativeIdentity value changed, ISC treats it as a different account and the link with the original identity can be lost.

A few recommendations that might help:

Ensure the same nativeIdentity is returned after provisioning

The DN generated during provisioning should match the DN returned to ISC. If the Before Provisioning rule modifies it, the rule should return the final DN that will exist in AD.

Avoid modifying the DN after the Create operation

If the DN changes after account creation, ISC may not track the account correctly.

Use stable correlation attributes

Since you mentioned employeeNumber is unique, make sure the correlation configuration prioritizes employeeNumber or sAMAccountName rather than DN.

Handle duplicate names before DN generation

For example, generate a unique CN using:

firstname.lastname

firstname.lastname1

or use sAMAccountName as part of the CN

This way the DN remains unique from the beginning, and ISC does not need to change nativeIdentity after provisioning.

Based on the IQService logs you mentioned, it looks like the modify operation is being triggered with a different nativeIdentity, which is likely causing the incorrect correlation.