Self-Service Troubleshooting Policy

Document created by RSA Information Design and Development Employee on Jun 13, 2017Last modified by RSA Information Design and Development Employee on Jan 24, 2020
Version 13Show Document
  • View in full screen mode

The self-service troubleshooting feature allows Self-Service Console users to troubleshoot routine authentication problems when they cannot access protected resources using primary methods, such as passwords or passcodes.

The self-service troubleshooting policy defines an alternative form of authentication, such as security questions, used to access the Troubleshooting feature. The policy also specifies the circumstances that lock a user out of the Troubleshooting feature.

You must select one of the following methods to unlock users:

  • System automatically unlocks user accounts after a specified amount of time

  • Administrators unlock user accounts manually

You can manually unlock a user’s account at any time.

You assign these policies to security domains. The policy applies to all users assigned to the security domain.

Self-service troubleshooting policies assigned to upper-level security domains are not inherited by lower-level security domains. For example, if you assign a custom policy to the top-level security domain, all new security domains that you create below it in the hierarchy are still assigned the default self-service troubleshooting policy.

Self-service troubleshooting policies allow you to define secondary authentication methods. A secondary authentication method allows a user to access the Self-Service Console even if the primary authentication method is not working.

Note:  Self-service troubleshooting policies only determine the lockout criteria for the self-service troubleshooting feature. To set lockout requirements for the Self-Service Console, Security Console, and resources protected by Authentication Manager, see Lockout Policy.

Self-service troubleshooting policies apply to all logon attempts regardless of how many different tokens a user uses to authenticate. For example, if a user has two unsuccessful attempts with a software token and one unsuccessful attempt with a hardware token, that counts as three unsuccessful attempts.

 

 

We want your feedback! Tell us what you think of this page.


Attachments

    Outcomes