Password reset on Cisco ASA without downtime for active /standby failover scheme

Recently I encountered a problem: the client has two Cisco ASA 5512-x, which work in the active /standby mode. The client forgot to update the passwords and all users have expired password. ASA when trying to log in just reports the expiry date and does not give the chance to change the password. Since the expiration date has expired for all users, it was not possible to connect and change the password in any way. It has always been an iron variant to reset the password by changing the register, but there's no getting around without downtime. This option was not suitable. It was decided to use standby ASA to avoid downtime. But also there were their nuances:
1) If you simply reboot the standby ASA, go in ROMMON mode, change the case and boot, we will get access and will be able to change the passwords, but as soon as we make
copy startup-config running-config
then immediately standby ASA will find the active node and will already synchronize the config from there.

2) If you disable synchronization and then upload the configuration, then standby ASA will take active ip addresses and we will have a conflict.

After reflection, the following plan was invented.

1. Reboot standby ASA, go to ROMMON, change register to 0x41 and load:

    rommon # 1> confreg 0x41
rommon # 2> boot

2. Now we disconnect all interfaces of standby ASA (it is possible on the switch where the ASA is connected or simply pull out all the network cables from the ASA itself).

3. Enter the privileged EXEC mode:

    hostname> enable    

and load the working configuration:

    hostname # copy startup-config running-config    

Here standby ASA without active interfaces can not not synchronize the data, do not harm the ip address conflict, if it considers itself to be an active node. We go into the configuration and add a new user for further access:

    hostname # configure terminal
hostname (config) # username test password test

4. Here you can do differently, do not connect cables, only at the end physically connect the cables that we have disconnected, or disconnect the interfaces from the configuration. At this stage, it was decided to disable all interfaces through the configuration.

    hostname (config) # interface interface_id
hostname (config-if) # shutdown

5. Return the register by default, save the configuration and reboot.

    hostname (config) # no config-register
hostname (config) # write

Now standby ASA is loaded with the config and the test user we need. Find an active node for synchronization standby ASA will not be able to do so, as the interfaces are turned off, and becoming active will not spoil anything for the same reason.

6. Now after downloading with the desired configuration, we can connect user test. We connect and enter privileged EXEC mode. Next, turn on the interface or interfaces that were designed for failover. After that, our standby ASA will find the active node, synchronize the configs and go into standby mode. In this case, our user test will be deleted, but since at this point we already find in privileged EXEC mode, our session will remain. If we leave at that moment, then we can not go in, so you have to be extremely careful here. Also, all other interfaces will be turned on due to the synchronization of the configuration from the active node.

We can change passwords of users only on the active node, but we still do not have access to it. The way out is to make our stanby ASA active with our already existing access. When our standby ASA goes into the standby ready state after this with an active node, you can make a switch. You can view the status using the command:

    hostname (config) # show failover state    

And with the help of the second command, we switch from Active ASA to Standby ASA:

    hostname (config) # failover active  
7. Now we have access on the active node. Here it is already possible to change user passwords and switch back if necessary (if this is critical).
Thus, we can reset passwords without downtime in this scheme without downtime. You only need to take into account the delay when switching from an active node to a standby node.
+ +1 -

Comments 1

ruslan 26 July 2018 18:04
add link to original post

Add comment