Problem
You want to ensure that your router can still authenticate user sessions even if it loses access to the TACACS+ server.
Solution
It is important to make sure that you can still enter commands on your router if your TACACS+ server becomes unreachable for any reason. The following set of commands ensures that you don't lose functionality just because you lose your server connection:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#aaa new-model Router1(config)#aaa authentication login default group tacacs+ enable Router1(config)#aaa authentication enable default group tacacs+ enable Router1(config)#aaa authorization commands 15 default group tacacs+ if-authenticated Router1(config)#tacacs-server host 172.25.1.1 Router1(config)#tacacs-server key COOKBOOK Router1(config)#end Router1#
Discussion
One of the potential problems with using a central server to authenticate user access is the issue of what happens when you lose access to that server. It would not be terribly useful if you couldn't plug in a console device and reconfigure the router to fix the problem that caused the router to lose access in the first place. But, by default, a router that can't communicate with its AAA server can't authenticate or authorize users.
Fortunately, Cisco's AAA implementation also includes the ability to do authentication locally on the router in case it can't reach its TACACS+ server. Cisco documentation often refers to this authentication as the "password of last resort." The various authentication methods available within the AAA feature set are shown in Table 4-1.
Keyword | Definition |
---|---|
tacacs+ | TACACS+ authentication |
radius | RADIUS authentication |
line | Line-based authentication (password) |
local | Local username authentication |
local-case | Case-sensitive local authentication |
enable | Enable password or enable secret |
none | No authentication |
The example in this recipe shows how to use the router's enable password as a redundant authentication method by adding the keyword enable to the aaa authentication command. As long as the primary authentication method is working, TACACS+ in this case, the router never uses this password of last resort. However, when the server connection is lost, users will be prompted for the enable password instead of the TACACS+ username and password. This ensures that you will never be locked out of your routers.
You can also implement other backup authentication methods such as local authentication, line-based passwords, and even RADIUS. However, we recommend using the combination of the enable password method shown in this recipe, along with an enable secret password, for two reasons. The first reason is that this password is local to the router, so it will never become unavailable. Second, when you use enable secret passwords, the router stores the password using MD5 encryption internally, which will help protect it from prying eyes. We should also mention in passing that it is possible to string together a few different methods of authentication, although it's usually not necessary.
This example assumes that we are doing command authorization as well as authentication. The same issues apply here. It doesn't do you any good to get into the router if the router can't verify which command you are authorized to use. This is why we have included the if-authenticated keyword in the aaa authorization command:
Router1(config)#aaa authorization commands 15 default group tacacs+ if-authenticated
We highly recommend using the if-authenticated option whenever you enable AAA authorization.
See Also
Recipe 4.1; Recipe 4.2
Router Configuration and File Management
Router Management
User Access and Privilege Levels
TACACS+
IP Routing
RIP
EIGRP
OSPF
BGP
Frame Relay
Handling Queuing and Congestion
Tunnels and VPNs
Dial Backup
NTP and Time
DLSw
Router Interfaces and Media
Simple Network Management Protocol
Logging
Access-Lists
DHCP
NAT
First Hop Redundancy Protocols
IP Multicast
IP Mobility
IPv6
MPLS
Security
Appendix 1. External Software Packages
Appendix 2. IP Precedence, TOS, and DSCP Classifications
Index