Good afternoon,
I’ve just created a Service Account profile & source for our new tenant. Is it possible to exclude accounts under that profile from MFA?
I’m thinking about ease of access and break glass scenarios
Thanks
Phil
Are you looking for those accounts to use only the ISC password, and not go through the MFA?
In the IdentityProfile for your Service Accounts, you can choose how they sign-in to the system from the “Sign-In Method” section. You can review the IdentityNow Admins profile as an example. (Do not use that profile for your service accounts, but you can use it as an example.)
If you have an External Identity Provider set up under Global, I am not sure how that affects it.
Hi @gmilunich
Thanks for that.
All my profiles are set up as this:
But everyone is required to MFA in. There must be a setting in Global somewhere (not that I can find it) that is defaulting it to MFA
Phil
In December 2023, SailPoint changed the requirements for accessing the admin interface. As part of this change, all Identity Security Cloud users with elevated permissions will be required to configure a Time-Based One-Time Password (TOTP) device. Refer to the SaaS Updates for more information.
Hope this helps
I would then look at the Global → Security Settings → Service Provider section. Remember that these are global settings, so review them carefully.
So as services accounts need admin access to be able to generate PATs, now require MFA, which means that they have to be tied to an individual.
Therefore the service accounts need to be updated if that user leaves the business.
Have I got that right?
Partially, I order to generate a PAT token you would need to have identity created for service account.
If you correlate it to actual identity (owner/manager) then PAT token will be created with identity that service account is correlated to.
Just following up on this one as I do not think Phil’s scenario was fully addressed and we fall into the same issue.
We have created an identity for a service account (e.g. IDN Automation) and, while logged in as that identity, we created some PATs that are used as part of our automation tools. This means that the PATs are not tied to a human that could leave the company.
BUT - Now that every identity that has elevated privileges in ISC must have configured a Time-Based One-Time Password (TOTP) device, this means when we try and log in as our service account identity (IDN Automation) we are forced to configure the TOTP on a human’s phone.
So when someone else needs to log in as that identity, the TOTP is with a different human that may have since left the company. The only way around this is for another Admin of ISC to log in and reset the service account identity’s MFA.
In a break glass scenario where only local authentication is available, another admin may not be able to log into ISC to do this reset (effectively meaning there is no break glass option)
Your break-glass accounts should be tied to specific people, though. As a matter of best practice, you should never use service accounts interactively - they should only be used for automated processes. You should configure the TOTP to generate the API keys for the service account(s) and then lose the TOTP, but the TOTP for each admins’ break-glass accounts should live with them.
As @sup3rmark mentioned, you should only use personal access tokens with your service accounts. Interactive logins using authorization code would be an unnecessary step to achieve automation. Setting up the TOTP for a service account is an annoying extra step, but once you do it once and generate the PATs, you shouldn’t need to log back into the Admin UI unless you need to update scopes on the PAT or generate new PATs.
The MFA doesn’t prevent you from using service accounts, but it is an extra step that makes the process more burdensome.
1 Like
what happens if the person with the device TOTP was set up on leaves the company?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.