I’m looking for guidance on the best way to enable login to SailPoint Identity Security Cloud using a privileged admin account.
Context:
Our identities are not sourced from HR; instead, Identity creation in SailPoint is driven by membership in specific Okta groups.
My standard account (luis.sebastiao) is already the primary identity in SailPoint.
My privileged account (adm.luis.sebastiao) already exists in Okta, is fully provisioned, and is correctly correlated to my main SailPoint identity.
The correlation works as expected.
What I’m trying to achieve:
I need the adm.luis.sebastiao account to be able to log in to SailPoint ISC and act as the account used for SailPoint administrative actions (e.g., Super Admin role).
Since SailPoint roles are assigned at the identity level, not on individual accounts, the requirement is simply to allow authentication using this admin account while keeping everything linked to the same identity.
This is because I need that, when a UAR happens, that the privileged access can be reviewed for the luis.sebastiao even if the account that holds that privilege is the adm.luis.sebastiao one.
I would like to understand the recommended or supported way to allow a secondary correlated admin account to authenticate into SailPoint ISC. Any suggestions?
Why does it need to be correlated to your standard account? To make sure it is properly terminated if the user ends up leaving? We had something similar setup but ended up deleting all of our secondary ADM accounts, moving to just in time access on our one standard account for priv stuff, and created separate Source (Generic) that we flat file with just one break glass account to ISC. Saved our security team headache and $$$
Yes the reason we need this correlated is exactly that, we need a way to make sure when we leavers that their access can be correctly deactivated and I also need to make sure when we do a UAR that we can certify their access under a single account
You need a completely separate identity which is created based on the admin account. This way only that admin identity has the elevated privileges assigned to it. To do this, you basically create a new AD source, filter the users aggregated by a specific group membership, and then create a new identity profile where that AD source is the authoritative source for it.
You then can either enable pass thru authentication on that identity profile and have admins use the direct login page of ISC if they are checking out their credentials from a PAM tool, or you could technically set up SSO as well. The issue there is there is only one SAML correlation attribute, so it needs to work for both your standard identities and these new admin identities. Additionally, they typically need to use an incognito window in their browser so they can be logged in as the admin account in that session (browser will prompt for creds during SAML redirect).
You also can then set up a role that any identities from that special source can automatically receive the admin ISC role to automate a bit if you want to.
Your concern about having the admin account still correlated to the regular identity is totally valid. This is reason for the new special AD source. Leave your current setup as is where your admin accounts are being correlated to the normal identity. When that identity is terminated or certified and the special group that allows them to be aggregated in on the special admin source is removed, that account would then drop on the next aggregation and therefore prune that special admin identity, revoking their ability to log in with that identity any longer.
@luissebastiao The easiest way would be to manage the identity admins manually. But disable the direct login to ensure they login only using SSO, this is to ensure once the priv account is terminated that user will not be able to login.
There are other complex ways to achieve it also, please let me know if you want other approaches as well.