New Capability: TOTP Device Configuration Required for All Elevated Users Starting Next Week

Announcements Product News
, ,
63

If we use an IDP will admins still need a 3rd party TOTP app?

64

We cannot configure Sandbox and Production TOTPs on the same authentication app.

1 Like
65

Nai - they still need to register a TOTP device that will only be needed if/when they log in locally. We can roll back temporarily for you while we figure out a solution. What is your tenant?

66

@gkiris1 Have them change the name in the app

IMG_5712
IMG_57121290×1360 86.2 KB

68

Hi Tyler,
I had renamed the existing record before adding the new one but it didn’t work for me, overwrote existing one.

1 Like
69

As I understand this, we now need to direct current and future elevated users to:

  1. Install an authenticator app
  2. Register
  3. Then never use the app or TOTP again

That is a terrible user experience.

Users that authenticate via an Identity Provider are never prompted to set their password. Why is this different?

1 Like
70

Kurt

You are more or less correct. Hopefully, everyone will be authenticated via SSO and will not need to access SailPoint locally. The key here, however, is that once Admin Step up (strong auth) is deprecated in a few days, then admins will be able to log in and access admin functions on a local account with only a user name and password. This is to protect your break-glass accounts, as well as protect admin account which have the ability to bypass SSO. I hope that context helps.

71

The part that feels really bad about this though, is that the registration is throw away.

This sets a bad example for our users, where we are ‘training’ them in this case that use of an Authenticator app for TOTP is something to discard. When that is otherwise far from the case. That is not something that I as an Identity administrator wants to encourage, instruct document for our users. Even more so when the system in question is an IAM solution.

If the account doesn’t have a password, there shouldn’t be a need for an MFA registration. That account can’t even be used to the get to the point in an authentication to trigger an MFA prompt.

1 Like
72

Multiple IDN environments overwriting in our MFA apps also happens for us.

73

Hey @Tyler_Harman ,
I have one question on “shared or service accounts” within IDN that are created so they can be used by multiple IDN administrators for performing day-to-day tasks in IdentityNow.
If we attempt to locally login to IDN using these accounts, I believe it will not work for all, as each identity is tagged to respective ToTP device.

Any best practice you would suggest here for this scenario?

74

We had to find a Shared Service TOTP generator (SW you run on a PC, instead of a phone). Our organization uses CyberArk, which has one, we had to use the registration code instead of the QR code, but it worked.

There are likely other companies/options out there.

3 Likes
75

Guarav

What @ccarlton mentions with regards to a separate Privileged Access Management solution, like CyberArk, is best practice for shared accounts, especially for your break-glass account.

Other options are to have an authenticator app, such as LastPass or Authy, which have Windows, MacOS, or Linux apps, so you can have that OTP generated on a central computer.

Lastly, you could have a manager be the one to register the TOTP device, and then they need to provide the code to anyone logging in.

2 Likes
76

Thanks @Tyler_Harman @ccarlton !!

1 Like
77

With this update live on customer tenants, is there a possibilty for any of the below for breakglass account for IDN:

  1. Bypass the TOTP
  2. Feasibility to use a phyical token (e.g. RSA SecureID Token) instead of a mobile/desktop based authenticator
78

Great questions!

We don’t have the capability to bypass TOTP onlyemphasized text** for a break-glass account. If you bypass TOTP, it removes it for everyone.

We also don’t have the capability to use a physical token for TOTP.

79

When will RSA be usable for MFA again?

80

After a cursory read of this thread, I didn’t find an answer so feel free to point me to it if I missed it.

We have a case where we’re using Azure as the IDP (no-MFA currently required for Azure though) to enable SSO. When a person logs in via SSO/IDP with admin rights they’re being prompted for the “legacy” step-up authentication options like they’ve always had. If this same person logs on via username/password they’re prompted for the TOTP as expected. The person/identity is definitely registered for TOTP in ISC as seen during the username login process.

Is this expected behavior for the SSO/IDP login?

81

Hi Ed

This is expected behavior. They are still being prompted for the step up auth on the admin tab because it hasn’t been deprecated yet. That deprecation in prod starts Feb 5-8, next week, after which point they will not ever do the step up auth again.

Either they login via SSO, and will not need another MFA, or they log in locally and are prompted for TOTP.

Let me know if you have any other questions. Thanks!

Tyler

1 Like
82

Nai

You can still use RSA. You can configure it for a TOTP option, and you can also configure it for password reset.

Configuring Security Integrations - SailPoint Identity Services

Configuring User Authentication for Password Resets - SailPoint Identity Services

I hope that helps.

Tyler

83

Hi Tyler,

When we scan the TOTP barcode with the RSA Authenticator app, it does not work. Looks like it can’t be configured for TOTP.
We currently have RSA setup for the admin step up and it is working. There doesn’t appear to be an option to use our existing RSA integration as the MFA for admins when they login directly to idn.

When will it be enabled?