Manager Correlation Failing for Subset of Identities Even Though managerId Exists

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

:bangbang: 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.

Hello everyone,

We are investigating an issue with manager correlation in SailPoint ISC and would appreciate any guidance.

Environment

  • Authoritative Source: OpenLDAP
  • Manager Correlation configured on the source
  • Approximately 506 identities affected

Current Configuration

Our authoritative source provides a managerId account attribute which contains the manager’s employee number.

Manager Correlation is configured as:

Employee Number (Identity Attribute) = managerId (Account Attribute)

Within the Identity Profile, the Manager Name (manager) identity attribute is mapped to managerId.

For most identities, this configuration works correctly and the manager identity is successfully linked and populated in ISC.

Issue

We currently have around 506 identities where the manager relationship is not being established.

For the affected identities:

  • managerId is populated on the account.
  • managerId values appear correct in the source extract.
  • The referenced manager account exists in the authoritative source.
  • The corresponding manager identity exists in ISC.
  • The manager’s Employee Number appears to match the managerId value.
  • Other identities using the same configuration are correlating successfully.

Because the configuration works for the majority of identities, we are struggling to determine what is different for this subset.

Troubleshooting Performed

We have already:

  • Verified managerId is present on affected accounts.
  • Verified the referenced manager account exists in the source.
  • Verified the manager identity exists in ISC.
  • Reviewed exported source data and checked for leading/trailing spaces or data quality issues.
  • Attempted to reset affected accounts. However, the reset operation could not be completed because ISC reported that the source owner account still existed on the source.
  • To rule this out, we changed the source owner to a test account that does not exist in the source, but the same behaviour persisted.
  • Removed accounts and re-aggregated.
  • Performed an unoptimised aggregation.
  • Reprocessed identities after aggregation.

None of the above resulted in the manager relationship being populated.

Interesting Observation

While reviewing some of the affected identities, we noticed a potential pattern.

For several affected identities, we took the managerId value and identified the corresponding manager record. We then looked for other employees referencing that same managerId.

In these cases we observed that:

  • Multiple employees reference the same managerId.
  • The manager account and identity exist.
  • None of the employees linked to that particular managerId have their manager populated in ISC.

This makes us wonder whether the issue could be related to specific manager records rather than specific employee identities.

We have only manually validated a few manager populations so far and cannot yet confirm whether this pattern applies to all 506 identities.

Questions

  1. Has anyone encountered a scenario where manager correlation works for most identities but fails consistently for employees under specific managers?
  2. Are there any manager-specific attributes or identity conditions that would prevent manager correlation from completing successfully?
  3. Is there a recommended way to troubleshoot manager correlation for a specific manager/employee pair in ISC?
  4. Beyond account reset, identity refresh and unoptimised aggregation, are there any additional steps that can force manager correlation to be recalculated?
  5. Are there known OpenLDAP-specific considerations that could impact manager correlation behaviour?

Any suggestions, troubleshooting ideas, or similar experiences would be greatly appreciated.

Thank you.

2

Hi Himaghna,

Did you make sure there’s only one identity with that id? Maybe for some reason these managers have another identity, for example a break glass identity as well. When there’s more than one identity that fits the correlation, the manager name field remains blank.

3

Heello Himaghna. This looks manager-specific rather than an OpenLDAP issue, and the pattern you found strongly points to that.

For one failing managerId, run this in ISC Search:

employeeNumber:"<managerId value>"

It should return exactly one identity.

If it returns zero, check the manager’s identity directly and confirm Employee Number is populated with the exact value. It may exist on the LDAP account but not be mapped correctly to the identity attribute.

If it returns more than one, check for an old, test or secondary identity using the same Employee Number. Manager correlation needs that value to identify one manager, so duplicate matches can leave the manager blank.

Aggregation and identity processing will recalculate the manager, but only if the underlying match resolves to exactly one identity. That’s why the steps you already tried didn’t change anything.

After correcting the data, process one affected employee again. If you changed the manager’s Employee Number, process the manager first and then the employee. A source reset should not be needed.

Also, if Employee Number is a custom identity attribute, confirm it is enabled as searchable for manager correlation. This is separate from ISC’s Search functionality.