How to recover if you are locked out from administering SecureLogin in ConsoleOne

Issue

User logged on as CN=Administrator.OU=NewYork.O=ACME and set the following preferences to ""No"" at the Organization Unit OU=NewYork.O=ACME.

Allow users to view and change preferences = No Allow users to view and modify application definitions = No

When the settings were applied, they were unable to administer SecureLogin, even as the Administrator user in the NewYork container. There was a warning box within ConsoleOne advising them this was the case but they didn’t read it.

Now they can’t administer SecureLogin and appear to be locked out of the management tools.

When they attempt to access the SecureLogin tab on the OU=NewYork container using ConsoleOne, the following error appears:

SecureLogin Configuration Access Denied You do not have rights to access SecureLogin configuration.

Cause

By setting these options to No, all users in that container and below, including Administrator whose user object also resides there, will be locked out from viewing and changing settings and scripts (unless user specific settings are made first as explained below).

Solution

Depending on which container the settings were applied to you may be able either logon as another user or create another OU and another user object at or above the level the setting was made. You can then grant administrative rights for the user you created by setting the above settings to Yes. Once this has been done, you can either set the option back to Yes on the OU or specifically on the user object desired e.g. CN=Administrator. In this case, the customer was able to logon as CN=Admin.O=ACME and change the settings back to Yes.

Any changes you make specifically on the user object override changes you make on OUs. User settings apply. CN=Administrator will then be able to administer SecureLogin. If you can’t logon as another user or create another user with administrative rights, contact Technical Support, who can help solve the problem.

Note: Before setting these preferences to No at the OU level to apply to all users in that OU, you should first set preferences to enable SSO Administrators and the user you are logged on as to manage SecureLogin.

For example, you should NOT set the options to ""Allow users to view and change preferences"" and ""Allow users to view and modify application definitions"" to No or you will prevent ALL users in the Users container from administering SecureLogin (which is what this article addresses).

To prevent this from occurring, first grant the ability to view and change settings, view and modify scripts etc. via the SecureLogin tab under the properties of the SSO administrator’s user object (e.g. CN=Administrator).

Once you have done this, you can then turn them off at the container level and the user specific settings will apply and you will be able to perform SecureLogin administration with the Administrator user, while all other users will be locked down as desired.