Recovering admin console access

From Swivel Knowledgebase Wiki

Contents 1 Overview 2 Prerequisites 3 Symptoms 4 Solution 4.1 Required Steps 4.2 How to edit the config.xml 5 Additional Considerations 5.1 Check Repository Password 5.2 Third Party Authentication (e.g. PositiveID) 6 Next Steps 7 Troubleshooting

Overview

This details how to regain admin access when all available admin accounts are locked, by setting the login back to shipping mode, the user can then set the system back to their own database, without losing any data, retaining all the user accounts, and information. Whilst Tomcat is stopped, users will not be able to authenticate.

Prerequisites

PINsafe is running and an admin login screen is available

Access to the OS on which PINsafe resides

Scheduled downtime to during recovery process

Symptoms

Cannot login to the PINsafe admin console through any admin accounts

Solution

If a PINsafe appliance is being used and the CMI is version 2.0.10 or higher then the PINsafe can be set to shipping mode to gain access, see Recovering admin access on appliance

Required Steps

The following steps need to be undertaken;

1). Stop Tomcat

2). Make a backup copy of the config.xml

3). edit the \<path to Tomcat>\webapps\pinsafe\WEB-INF\conf\config.xml

4). Start Tomcat

5). Login with admin and PIN 1234

6). Set the database back to its correct setting from shipping.

7). set the admin users PIN, ensure the admin users accounts are not locked.

Example: C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\pinsafe\WEB-INF\conf\config.xml

How to edit the config.xml

For PINsafe versions 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8 change the selected="true" as below

From

<section name="database">
    <group name="general">
      <choice name="database">
        <option generated="true">Shipping</option>
        <option generated="true" selected="true">Internal</option>
        <option generated="true">JDBC</option>
        <option generated="true">MS SQL Server</option>
        <option generated="true">MySQL 5</option>
        <option generated="true">Oracle 10g</option>
        <option generated="true">PostgreSQL 7.4</option>
      </choice>

To

<section name="database">
    <group name="general">
      <choice name="database">
        <option generated="true" selected="true">Shipping</option>
        <option generated="true">Internal</option>
        <option generated="true">JDBC</option>
        <option generated="true">MS SQL Server</option>
        <option generated="true">MySQL 5</option>
        <option generated="true">Oracle 10g</option>
        <option generated="true">PostgreSQL 7.4</option>
      </choice>

For PINsafe versions 3.1.2 to 3.1.4 Change the following section

From

<section name="repository">
    <group name="general">
      <choice name="repository">
        <option>none</option>
        <option generated="true">XML</option>
        <option generated="true" selected="true">Active Directory</option>
      </choice>

To

<section name="repository">
    <group name="general">
      <choice name="repository">
        <option generated="true" selected="true">none</option>
        <option generated="true">XML</option>
        <option generated="true">Active Directory</option>
      </choice>

For PINsafe version 3.1.1

To

<section name="repository">
    <group name="general">
      <choice name="repository">
        <option selected="true" selected="true">none</option>
        <option selected="true">XML</option>
        <option selected="true">Active Directory</option>
      </choice>

For PINsafe version 3.1

To

<section name="repository">
    <group name="general">
      <choice name="repository">
        <option selected="selected">none</option>
        <option>XML</option>
        <option>Active Directory</option>
      </choice>

Hint: To find the section to edit search for ‘shipping’ (or before 3.2 ‘repository’)

Additional Considerations

Check Repository Password

If using Check Password with Repository, in versions of PINsafe prior to 3.7, this may need to be reset:

From

     <boolean name="checkpasswordwithrepository">
       <default>false</default>
       <value>true</value>

To

     <boolean name="checkpasswordwithrepository">
       <default>false</default>
       <value>false</value>

In 3.7 and later, repository password settings are configured per agent, and are never applied to the admin console, so this is no longer relevant.

Third Party Authentication (e.g. PositiveID)

See Also: PositiveID How to Guide

Certain third party authentication settings can prevent authentication. In particular, since PositiveID will not work with normal single-channel authentication, only with the PINsafe taskbar client, selecting the shipping database will prevent PositiveID users from authenticating (the admin user in the shipping database cannot be provisioned for PositiveID).

Therefore, if you have PositiveID enabled, you will have to disable it temporarily to access the PINsafe admin console.

To do this, locate the following line in config.xml:

   <group name="thirdparty">

and just below that, the following:

         <string name="id" readonly="true">
           <value>PositiveID</value>
         </string>

Below this, locate the following line:

         <choice name="group">

In the following option settings, make sure only the first item, labelled displayValue="repository_groups_no_group", has selected="true". So, for example, if the current text shows

         <choice name="group">
           <option displayValue="repository_groups_no_group">-</option>
           <option generated="true">PINsafeAdministrators</option>
           <option generated="true"" selected="true>PINsafeUsers</option>
         </choice>

Change it to the following:

         <choice name="group">
           <option displayValue="repository_groups_no_group" selected="true">-</option>
           <option generated="true">PINsafeAdministrators</option>
           <option generated="true">PINsafeUsers</option>
         </choice>

Next Steps

Once access to the system has been obtained set the database back from Internal to the correct value and click Apply, then verify why the the admin accounts to see if they have become locked. This must be resolved before logging out of the Administration console. Common causes are:

• Does the administrative user account exist (check data source)
• Has the admin account become locked
• Is password expiry used
• Reset the PIN
• Reset the password (even to a blank value if no passwords are being used)
• Check the PINsafe logs for the reason it became locked
• Verify login from another browser type or another server/pc

Troubleshooting

If the admin user cannot login with the admin user and a PIN 1234 after this then the likely reasons are:

• File has not been edited correctly. Check for errors in the edited config.xml
• admin user is incorrectly carrying out the PIN extraction
• admin user is entering a password or their OTC in the password field instead of the OTC field
• If the changes are made but the config.xml keeps reverting back to the original configuration, then the file may have been edited incorrectly and loaded the config.xml.bak file instead.