dslreports logo

    All FAQs Site FAQ DSL FAQ Cable Tech About DSL Distance DSL Hurdles »»


how-to block ads


In smaller network environment, pretty much anybody can log into network devices such as routers, switches, and firewalls to make configuration changes. To provide further network access protection, some username and password is stored locally within the network devices.

A downside of such localized credential is that there is minimum or no control of such credential integrity. As illustration, someone could just login and changes password without telling others. Then others can no longer login without knowing the new password.

The best practice to have more control is to have centralized AAA (Authentication, Authorization, Accounting) server that keeps all usernames and passwords for user login authentication. Further, the AAA server can authorize certain tasks or commands that certain users are able to perform. When such users try to do tasks or issue commands that are unauthorized, those tasks or commands will be rejected. In addition, the AAA server can run report which users are accounted for which tasks or command issues on some network devices.

Various Privilege Level and Centralized AAA server

Let's say there are network engineers and network analysts as people who have authorized access to routers. The network engineers have full access to routers from issuing show, ping, traceroute commands for troubleshooting; to issuing configure terminal command to configure the routers. The network analysts have partial access to routers. These analysts are only allowed to troubleshoot and are not allowed to configure routers. Only the engineers have such authorization.

Typically these network analysts are only allowed to issue show, ping, traceroute commands for troubleshooting. They are not allowed to issue configure terminal command since such command is part of configuration command which only network engineers have privilege of.

As you can see, there is a need to have different privilege level between network engineers and network analysts. In AAA world, there is something called Privilege Level 0, 1, 2, all the way up to 15 when somebody (a user) access router or any network device. The Privilege Level 0 is the lowest privilege level a user can have where the Privilege Level 15 is the highest privilege level.

On Cisco router, by default a user can only issue simple commands such as show version, ping (not extended ping), and traceroute (not extended traceroute) when such user is authenticated as Privilege Level 0 user. A user can issue full commands when such user is authenticated as Privilege Level 15 user. Using the illustration, let's decide that the network analysts are set as Privilege Level 0 users and the network engineers are set as Privilege Level 15 users

Note that on Cisco router, a user can issue commands like show configuration or show running-config when such user is authenticated as Privilege Level 15 user by default. In this case, the network analysts need to issue such commands. To make this possible, there are several approaches you can use.

One approach is to define local credential by creating a list of commands on the router itself for Privilege Level 0 users. In this case, the show command set including show configuration and show running-config is within the list. Note that this approach is only feasible as the only platform of network access security and monitoring when there are only handful of routers. Once there are more and more routers, this approach is not scalable.

Another approach is to utilize external authentication server such as TACACS+ to keep this list of authorized commands for Privilege Level 0 users. By utilizing such TACACS+ server, there is no need to keep list of commands on the router itself. All authorized commands for any users (including network analyst and network engineers) are centralized within the TACACS+ server database. Therefore regardless of the router quantity, there are minimum to no changes needed when more routers or any network devices are deployed into the network.

In typical production network, both local and external authentication server utilization are implemented. The authentication server which stores centralized credentials is used primarily. The local credentials are used as backup in case there is an event where the authentication server is unreachable or non-working. By using this approach, there are several platforms of network access security and monitoring (centralized and local credentials) which from network management perspective is more secure, scalable, and practical.

TACACS+ server Management

Let's say now there is a centralized TACACS+ server to regulate which commands specific users can issue. Depending of TACACS+ server software capabilities, there are some TACACS+ servers that are unable to keep specific command set. Certain TACACS+ servers are only able to keep a list of command itself without its following parameters. As illustration, some TACACS+ servers are only able to keep show command but not show running-config or show configuration commands.

When you have to deal with these kind of TACACS+ servers, there is one approach to provide those show running-config or show configuration commands for Privilege Level 0 users. This one approach is to set those Privilege Level 0 users to have Privilege Level 15. However only handful commands that these users can issue such as show (including show running-config or show configuration), ping (both standard and extended), and traceroute (both standard and extended). When these users try to issue unauthorized command such as configure terminal, the command will be rejected as failed to authorize. This way, you can even have further control of which commands specific users can issue beyond a simple Privilege Level 0 and 15 distinction.

You can also configure TACACS+ servers to do further advancement. One is to authorize certain users to have access to only some network devices and to reject access to other network devices. When these users only come from certain IP subnet, then you also can utilize ACL (i.e. access-class command under line vty on Cisco routers) to restrict such access.

Another functionality is to grant full Privilege Level 15 to only some network device and to grant partial Privilege Level 15 to other network devices. This is applicable when you have wider network team such as Network Analyst, Network Engineer, and Advanced Network Engineer team; where Network Analysts can only troubleshoot, Network Engineer can troubleshoot and modify configuration on certain network devices only (typically edge network devices), and where Advanced Network Engineers have full access to all network devices.

Following is example of implementing such restriction
Cisco Secure ACS: Network Access Restrictions with AAA Clients for Users and User Groups

Between TACACS+ and RADIUS server

Beside TACACS+ server, there is another type of AAA server which is RADIUS server. Typically you implement TACACS+ server for network device access management such as routers, switches, and firewall. To have centralize management of others, you may need RADIUS server instead since RADIUS functionality is more of general purposes.

In addition, typically you need TACACS+ server to do AAA (Authentication, Authorization, Accounting) of user credentials, which Privilege Level the user will be as, which command the user can issue on certain network device, and to record all commands such user issues on certain network device. Since RADIUS is more of general purpose AAA server, RADIUS is typically only capable to either permit or deny access of certain network resources, and to record which users have been logging in from specific IP address to which device.

Last but not least, TACACS+ is Cisco implementation where it towards to more of network device centralized access management where RADIUS is IETF implementation for general purpose AAA functionality.

Check out following discussion for illustration.
»Problem in ACS4.1 and user monitoring

When to Implement TACACS+ and RADIUS server

You may wonder when you should implement TACACS+ and when you should implement RADIUS. One good example is remote VPN management access. In this example you provide IPSec VPN service to users that need to remotely access network resources from anywhere securely. The VPN device you use is PIX Firewall.

In general, there are two remote access management concerns. One is the PIX Firewall device management itself and another is the IPSec VPN service management. You basically need to centrally manage who has authorization to modify PIX Firewall configuration, to troubleshoot any connection passing through PIX Firewall, and any related issues. You also need to centrally manage who has authorization to remotely access network resources from anywhere, which network resource that such remote users are authorized to access, and any related issues.

TACACS+ technology (with proper AAA command set) is designed to provide greater control of CLI-based appliances. As mentioned previously, you can control which CLI commands (such as show, ping, and traceroute) that specific users can or cannot issue. RADIUS technology (also with proper AAA command set) is pretty much designed to provide general control of CLI- and non-CLI-based appliances. RADIUS technology cannot really control which CLI commands that specific users can or cannot issue on CLI-based command unlike TACACS+ as mentioned previously, however RADIUS can still be able to provide basic and/or general control of some appliance usage and management.

You may notice in the above example of remote access using PIX Firewall as the VPN device that the PIX Firewall is CLI-based appliance where other network resources in general are non-CLI-based appliances. Therefore you may want to implement TACACS+ server for the PIX Firewall device management itself (the CLI-based appliance management) and to implement RADIUS server for network resource remote access (the non-CLI-based appliance management). Check out the following FAQ for sample configuration.

»Cisco Forum FAQ »Configure PIX/ASA as both Internet Firewall and VPN Concentrator

There are other situations when certain network devices or applications only support RADIUS authentication for management such as Cisco MARS. In these situations, then you obviously have no choice but to implement RADIUS authentication instead of TACACS+ one.

AAA Command Set Implementation

As mentioned previously, there are in general two types of AAA accounts; local and centralized in either TACACS+ or RADIUS server. The local accounts are sets of username and password stored locally within network devices. The centralized accounts are sets of username and password stored in some TACACS+ and/or RADIUS server.

In addition, it is also typical practice to define which commands specific accounts or users are able to issue, especially when TACACS+ server is implemented. Similar to the account storage, this list of authorized commands can be either defined locally or centralized within the TACACS+ server.

Check out the following FAQ for details.

»Cisco Forum FAQ »Securing access to routers with AAA commands
»Cisco Forum FAQ »Securing access to switches with AAA commands
»Cisco Forum FAQ »Securing access to ASA/PIX Firewall with AAA commands

AAA Server Implementation

As mentioned, AAA server can act as either TACACS+, RADIUS, or both. For further control and security, it is also common practice to integrate AAA server with external authentication server such as MS Active Directory Domain Controller (Windows Database) and RSA SecurID Token. Using Domain Controller as external authentication of the AAA server, the Domain Controller can be the authentication center when log into either Windows machines or non-Windows machines such as router, switches, and firewall.

For network that requires greater control and security, typically electornic token ID server such as RSA SecurID or Vasco DigiPass Token authentication server is used as the authentication center instead of just the Domain Controller or the AAA server alone. This type of electronic token ID authentication involves communication between the Token server and the Token ID itself. This electronic Token ID changes typically every 15 seconds or so. With token authentication, someone needs to log into a machine (Windows or non-Windows) using the regular credential (either the Domain Controller credential, the AAA credential, or both) and the token ID that currently shows on the token display. With this great control, it will be harder for hackers to break into machines.

Following is more info on token system

Vasco DigiPass Go

Check out the following links for sample implementation.

»Cisco Forum FAQ »Are there Free TACACS+ or RADIUS authentication software to secure my router?
Implement RSA SecurID Token Authentication within Cisco ACS (AAA) server

Some discussions

»TACACS+ problems
»[Config] user account on cisco router 2611
»[Config] Hhow to configure Cisco IOS for students
»IOS and Active Directory intergration using Radius

Expand got feedback?

by aryoba See Profile
last modified: 2012-04-11 09:17:51