Account Name "Last Resort" Correlation


We’ve been looking at establishing a strategy for Service Accounts in our environment. We have a source (ServiceNow) that contains Service Accounts, which we intend to govern using certification campaigns. Given this goal, we decided the best approach would be to set these service accounts up as correlated to Identities.

One avenue we explored was to set a separate source definition of ServiceNow connector to ONLY pull back Service Account users and to treat that as an authoritative source via an identity profile. The catch with that is that we would’ve needed to be careful to ONLY associate the proper accounts with this identity, which we thought would be possible by being careful about our correlation rules for each source. However, after trying to test this, we noticed that a certain account with an Account Name of “admin” kept correlating to other generic “admin” Account name accounts despite no other correlation matching.

We realized that this was as a result of a sort of “last resort” correlation that happens matching identity cubes (Account ID and Account Name), per this blurb from this wiki doc:

Account Name is not as straightforward as Account ID. Its name implies that this attribute should be mapped to an account attribute which contains the user’s display name or an otherwise human-friendly value. This is incorrect. Account Name designates the “name” of the account being aggregated, which becomes the internal name for that “basic” identity cube. It is always a best practice to ensure that Account Name is mapped to an attribute that is guaranteed to be unique , much like Account ID. This is because the IdentityNow system will automatically check to see if any other “basic” identity cubes have the same Account Name value during a given account aggregation if no other correlation rules for that source are satisfied. If a matching cube is found, the new account will be correlated to that object instead of creating a new “basic” identity cube. This often leads to unintended correlation, and in extreme cases, can result in a significant downgrade to the tenant’s performance if hundreds of accounts have the same value for Account Name.

Unfortunately, we don’t have flexibility to set the Account Name for this Service Account to be more specific than “admin,” as a name change there could have unintended consequences for the rest of our environment (and we seemingly don’t have the ability to set the account schema of the connector such that the account attribute mapped to Account Name is different).

In light of this, we moved on from the idea of having a “direct connection” authoritative source for the service accounts in this instance, instead deciding that a delimited file would be easier to maintain and avoid unintended correlations. The obvious downside here is that it’s less easy to set and forget, as each access review, we’d need to validate that the flat file was still accurate.

Has anyone else run into this? Is it possible to flip this “last resort” correlation off? What kind of workarounds worked for others?

Hey Ian,

We had a similar use case we worked on with Service Accounts. The solution we landed on was to use a ServiceNow forum as the intake method for Service Accounts. The form takes the required fields we are looking for, then writes them to a delimited file source we have in IDN by calling the IDN API. This allows us to not have to maintain the delimited file source, while giving us that authoritative source to have identities for these Service Accounts. From that point, requests are submitted through the Request Center to get them the accounts/access the service accounts need. It also let’s instruct users on how to set/reset the password for Service Accounts through IDN password manager.

Is this something that could work for you? Or are you looking for a different solution?

Thank you,

  • Zach

Hi Zach,

Appreciate the response! That does sound like a good solution for working around not being able to count on a direct connection authoritative source set-up. I’ll see what my team thinks of this but I think it sounds like a promising route for us too.

Sounds great! If you want any additional information about this setup, please feel to reach out to me!

If your team agrees with this solution would you mind marking my response as a solution in this thread so future users that are looking for a potential solution can see that this solved your question/use case?

Thank you,

  • Zach

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