I have a customer using SailPoint IdentityIQ, and we’re looking for the best approach to manage service accounts.
Currently, when we aggregate these accounts from the target application, IdentityIQ creates new Identity Cubes for them because they cannot be correlated with any authoritative identity. As a result, they appear as uncorrelated identities.
Our goal is for these accounts to be treated and displayed as service accounts, rather than regular uncorrelated identities.
Has anyone implemented this successfully? Specifically, I’m looking for guidance on:
What is the recommended approach for managing service accounts in IdentityIQ?
Is there a way to aggregate them without creating separate uncorrelated Identity Cubes?
Should they be correlated to dedicated “service identities,” or is there another best practice?
Are there any SailPoint documentation pages or community articles that explain the recommended design?
Any recommendations or documentation would be greatly appreciated.
My recommendation is to go with option#3 in the link shared by @pasha . I have used option#2 but it causes lot of issues like slow aggregation since you cannot run partitioned aggregation as multiple partition might work on same service/application identity. Also if you want to enable access request for these service account it becomes tedious with option#2.
I agree on that. We assign the user who requested the service account as manager so we know who to contact when there is an issue as well as certification if needed.
@IslamElkhouly Cleanest approach would be #3. We have seen assigning this to single identities, but this causes during aggregation or refreshes where identities got locked and eventually failed due to time out. It also makes identities bulky.
Better to have a separate identities for each service account.. in case same identifier being used in the other applications, they all can safely correlate to the identity.