Self-Service Troubleshooting Policy

Document created by RSA Information Design and Development on Jun 13, 2017Last modified by RSA Information Design and Development on Jun 13, 2017
Version 2Show 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.

 

 


Attachments

    Outcomes