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.