We have a particular requirement where we have to correlate multiple AD accounts to a single identity. In order to identity that these multiple AD accounts belong to same identity, a custom AD attribute value (attr1) at AD accounts of the identity is set as the primary adid of the user
e.g. User John’s primary AD account is adid:John1. He has other secondary AD accounts with adids: John2, John3, John4, John5.
So John2 AD account’s attr1=John1
Similarly, John3 AD account’s attr1=John1
John4 AD account’s attr1=John1
John5 AD account’s attr1=John1
How can I correlate AD accounts: John2, John3, John4, John5 to John’s identity?
We have the same setup in our organization. All Users have a normal AD account. Some users have administrative access, so they have an additional “A” account. Some users have testing responsibilities, so may have an additional “T” account. A few users have a higher level of AD permissions and have a “DA” account. This means that users in our AD have 1-4 accounts, and we’d like to have IDN correlate all of these accounts back to a single identity, so we can manage these.
A common correlating attribute for sure is important, but that is not all that is needed.
I tried to do some of this in our sandbox environment and ran into some problems with our SSO (I believe SP was confused which account should be used to sign in)… I think there is some sort of account weighting/preference that needs to be done within a source? to help the SSO choose the right one? – Not sure.
How the accounts are structured OU wise, and How Groups are setup factor in too… Can A accounts and normal accounts intermingle in a group? are there groups that should only have A accounts…etc.
Also, you need to consider these accounts when it comes to provisioning new access.
Long story short, it’s possible but does require some more complicated things on the IDN side (I don’t think I know them all), and you are going to want to discuss it and plan it out ahead of time.
First, you can easily correlate multiple accounts from a single source to an identity. The trick is just what is the common attribute that links the account to the identity. For example, lets just say we use employeeNumber in AD to correlate to employeeNumber on the identity. If a user has 1,2 or even 3 or more accounts in AD with that attribute matching the identity, they will correlate.
Second thing to consider is do you want all these from the same source? I ask because there are things to keep in mind here. If you are performing attribute sync on this source, it will apply those sync rules to all accounts correlated from that source. this might be fine, but could cause issues too. Also, if you setup access profiles to provision entitlements from this source, you may need to configure the “Multiple Account Options” on the access profile with criteria that will select only one account out of the multiple an identity may have correlated. if the multiple acocunt options criteria is applied yet more that one account still meets that criteria, it will create an error.
You could consider different sources for different account types but still correlate on the same attributes. Say for example, a source for all admin accounts. We utilize the employeeType attribute in AD to tag those as “admin” and create a filter on the source for aggregation. I do not find it a good practice to use the account name to distinguish admin accounts. Anyway, this other source option gives you more flexibility. Either solution could work depending on your needs.
In Step 6. of the Configuring Account Correlation in the above article, it says you can specify more that one Correlation attribute pairing and it will do it in order listed. So in theory you should be able to have two correlation pairings. the first will be what ever attribute pairing you would use to correlate john1, then you would setup a pairing for attr1 to an identity attribute that would equal john1. I’ve tried using multiple pairs with varying results so i would test this.
Correlation means having a defined field in the source that matches EXACTLY with some attribute on the identity. John and John5 would NEVER correlate and likely never should. If there’s an immutable value (employeeID or similar) then this is the best case scenario for correlation. If not it becomes more challenging, but the OOTB option is using a 1:1 mapping of target attribute to identity attribute. Options exist for custom correlation rules if needed.
Additionally - The “type” of account is also CRITICAL to how you structure your sources in IDN. Primary, Admin, Secondary, etc. should all be separate sources in IDN. I’ve seen systems with multiple accounts that are all “equal” (neither primary, secondary, admin) to support security requirements of the downstream source (i.e. primarily in custom developed mainframe applications) which are a different set of issues to deal with in IDN.
We managed to correlate the cases. We are first trying to correlate the identity attribite adid of the user with account attribute sAMAccountName, and if thats not a match, next correlation logic is to correlate identity attribite adid of the user with attr1.