Restrictions for Controlling Switch Access with Passwords and Privileges
The following are the restrictions for controlling switch access with passwords and privileges:
-
Disabling password recovery will not work if you have set the switch to boot up manually by using the boot manual global configuration command. This command produces the boot loader prompt (switch:) after the switch is power cycled.
-
Password validation for the enable password command against the common criteria policy does not happen during configuration or reconfiguration of the aaa common-criteria policy command. The password is validated against the common criteria policy only during configuration or reconfiguration of the enable common-criteria-policy command.
In a high availability setup, if the active device is reloaded and then one of the criterion under the AAA common criteria policy associated with the enable password configuration is changed (such that the password no longer satisfies the common criteria policy) at a time instance between the manual reload of the active device and selection of the standby switch, the enable password configuration on the standby device fails during bulk sync, while the enable password configuration continues to exist on the active device. This configuration mismatch between the active and the standby devices triggers continuous reload of the standby device. We recommend that you do not modify the common criteria policy at a time instance between the manual reload of the active device and the standby switch selection.
Restrictions and Guidelines for Reversible Password Types
-
Password type 0 and 7 are replaced with password type 6. So password type 0 and 7, which were used for administrator login to the console, Telnet, SSH, webUI, and NETCONF must be migrated to password type 6. No action is required if username and password are type 0 and 7 for local authentication such as CHAP, EAP, and so on.
-
If the startup configuration has a type 6 password and you downgrade to a version in which type 6 password is not supported, you can/may be locked out of the device.
Restrictions and Guidelines for Irreversible Password Types
-
Username secret password type 5 and enable secret password type 5 must be migrated to the stronger password type 8 or 9. For more information, see Protecting Enable and Enable Secret Passwords with Encryption.
-
If the startup configuration of the device has convoluted type 9 secret (password that starts with $14$), then a downgrade can only be performed to a release in which the convoluted type 9 secret is supported. Convoluted type 9 secret is supported in Cisco IOS XE Gibraltar 16.11.2 and later releases. If the startup configuration has a convoluted type 9 secret, and you downgrade to a release prior to Cisco IOS XE Gibraltar 16.11.2, you can/may be locked out of the device.
Before you downgrade to any release in which convoluted type 9 secret is not supported, ensure that the type 9 secret (password that starts with $9$) must be part of the startup configuration instead of convoluted type 9 secret (password that starts with $14$) or type 5 secret (password that starts with $1$).
If a device is upgraded from Cisco IOS XE Fuji 16.9.x, Cisco IOS XE Gibraltar 16.10.x, or Cisco IOS XE Gibraltar 16.11.x to Cisco IOS XE Gibraltar 16.12.x, the type 5 secret is auto-converted to convoluted type 9 secret (password that starts with $14$). For example:
username user1 secret 5 $1$dNmW$7jWhqdtZ2qBVz2R4CSZZC0
is auto-converted tousername user1 secret 9 $14$dNmW$QykGZEEGmiEGrE$C9D/fD0czicOtgaZAa1CTa2sgygi0Leyw3/cLqPY426
. After the device is upgraded, run the write memory command in privileged EXEC mode for the convoluted type 9 secret to be permanently written into the startup configuration. -
Plain text passwords are converted to nonreversible encrypted password type 9.
Note
This is supported in Cisco IOS XE Gibraltar 16.10.1 and later releases.
-
Secret password type 4 is not supported.