Hi
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?