At some point, you need to onboard your network device to controlled access and configuration policy. Prerequisite is of course that user access and authorization to the network devices is centralized with one of the known methods like using RADIUS or TACACS protocols.
If your device is in your rack in DC close to your office, you can simply walk there in 5minutes or if it is on your table, process of protecting devices access by e.g. TACACS is not so risky task, you can start recovery procedure which sometimes requires power cycling device, more then once, especially if you missed to follow correctly recovery procedure, but what to do in case your DC is 500km far a way from your office?
Well in that case...you must be very careful to not lock your device. If we e.g. want to apply TACACS on Cisco ASR9000 router, we would need to create TACACS server group in our case called TAC_TEST and use that group as reference for default Authentication Authorization and Accounting process. Default means policy will be used for VTY or Console access in the same way.
aaa accounting exec default start-stop group TAC_TEST
aaa accounting system default start-stop group TAC_TEST
aaa accounting commands default start-stop group TAC_TEST
aaa authorization exec default group TAC_TEST local
aaa authorization commands default group TAC_TESTnone
aaa authentication login default group TAC_TEST local
With this setup, if TACACS group is not available, locally configured credentials will be used. How to enable AAA in safe way?
On Cisco ASR you can temporary apply commands for testing purpose certain period of time, and after timer expired, configuration will be revert. E.g. if you want to apply command to be valid in configuration for next 5 minutes you can use this command:
commit confirmed minute 5
Challenge with this command is that once applied, you can t exit config mode before you confirm previously applied commands for next 5 minutes, except you want to apply them permanently. To apply permanently before you test your access is not good approach. How to approach this safely?
Well, you should test first VTY access, simply start new SSH or Telnet session and if it is successful, it means you are good to continue. But before you apply AAA commands permanently you want to test console access, too.
To test console access you need to reestablish serial connection. To reestablish connection for a test, you need to exit configuration mode, and as we already know that is not possible if we do not want to apply AAA command permanently. So how to test it?
It is more simpler that you can imagine, you just need to use "do" command:
do clear line console location 0/RP0/CPU0 in config mode
Voila! You will be logged out from console and you can test access over console controlled by setup on AAA server.
What would be additional reason to test this properly? Well you could have local admin credentials which you are using to configure devices, but once AAA is applied your network credentials are read only, not admin. So if you do a mess with applying AAA permanently before it is properly tested, you will lock device to be accessed.
To recap:
Applying AAA on new devices doesn´t need to be stressful if you use prepared procedure in advance, and follow hierarchy of applying command and testing.