The self-service troubleshootingfeature 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.
You associate Self-Service Troubleshooting policies with security domains. The policy that you select for the security domain overrides the default policy.
In a replicated deployment, changes to policies might not be immediately visible on the replica instance. This delay is due to the cache refresh interval. Changes should replicate within 10 minutes. For instructions to make changes take effect sooner on the replica instance, see Flush the Cache.
In the Security Console, click Authentication > Policies > Self-Service Troubleshooting Policies > Add New.
In the Self-Service Troubleshooting Policy Name field, enter the policy name. Use a unique name, and do not exceed 128 characters.
(Optional) To designate the new policy as the default policy for the system, select Default Policy. When this option is selected, new security domains use this policy.
(Optional) Select the Authentication Method with which users authenticate if they cannot use their primary authentication method.
The Lock User Accounts field controls the number of unsuccessful authentication attempts a user is permitted to make to the Self-Service Troubleshooting feature. You can allow an unlimited number of unsuccessful attempts, or a specified number of unsuccessful attempts within a specified number of days, hours, minutes, or seconds. After the number has been reached, this policy locks the user's account out of the troubleshooting feature.
In the Unlock field, you can either require administrators to unlock accounts after users have exceeded the limit specified in the Lock User Accounts field, or you can allow the system to automatically unlock accounts after a specified number of days, hours, minutes, or seconds.
You can edit, view, or delete a self-service troubleshooting policy.
In the Security Console, click Authentication > Policies > Self-Service Troubleshooting Policies > Manage Existing.
Do the following:
Edit a self-service troubleshooting policy
You can edit a self-service troubleshooting policy to change information such as the policy name, the default policy, the alternative authentication method, and the circumstances that locka user out from the troubleshooting feature.
Click the policy that you want to edit, and select Edit.
Make any necessary changes to the policy.
If you have not saved your changes, you can click Reset to restore the policy to its original state.
Delete a self-service troubleshooting policy
When you delete a self-service troubleshooting policy, the policy is removed from the deployment and can no longer be assigned. Each security domain must have a self-service troubleshooting policy. If you delete a self-service troubleshooting policy that is assigned to a security domain, the default self-service troubleshooting policy is automatically assigned to the security domain.
Note:Before deleting the default self-service troubleshooting policy, you must first designate another policy as the default.
Use the search fields to find the self-service troubleshooting policy that you want to delete.
Click the policy that you want to delete, and select Delete.
Duplicate a self-service troubleshooting policy
When you duplicate a self-service troubleshooting policy, you create a policy with information that is identical to the original. You can edit the policy to customize it. The new policy is not assigned to any security domain until you manually assign it.
Click the policy that you want to duplicate, and select Duplicate.
In the Self-Service Troubleshooting Policy Name field, enter a name for the new policy, and make any other necessary changes to the new policy.