What is TACACS and How to Configure TACACS?

This document describes the Huawei Terminal Access Controller Access Control System (HWTACACS), including the relationship between Terminal Access Controller Access Control System (TACACS), Terminal Access Controller Access Control System Plus (TACACS+), and HWTACACS, the compatibility between HWTACACS and TACACS+, the comparison between HWTACACS and Remote Authentication Dial-In User Service (RADIUS), and the advantages of HWTACACS in command authorization and event reporting. In the last part of the document, Huawei S series switches are used as access devices to describe the basic configurations required to connect to a TACACS server.

This document uses Huawei S series switches running V200R019C10 as an example. For the functions and commands used on your switch, see the documentation of the specific version.

TACACS is an Authentication, Authorization, and Accounting (AAA) protocol originated in the 1980s. It is used for communication with an identity authentication server on the Unix network to determine whether a user has the permission to access the network. In later development, vendors extended TACACS. For example, Cisco developed TACACS+, whereas Huawei developed HWTACACS. TACACS+ and HWTACACS are proprietary protocols. They gradually replaced TACACS and are no longer compatible with TACACS.

HWTACACS is compatible with TACACS+. As an access device, an S series switch can connect to a TACACS+ server to implement AAA.

HWTACACS and TACACS+ define the same packet structure and type. The main difference between HWTACACS and TACACS+ is that the meanings or types of the attributes in authorization and accounting packets are different. For example, when a Huawei S series switch connects to a TACACS+ server to authenticate Telnet users, the basic authentication, user privilege level authorization, and command authorization functions can be implemented normally. If there are additional requirements, query HWTACACS and TACACS+ attributes. These requirements can be met when both HWTACACS and TACACS+ attributes are supported. Table 1-1 lists HWTACACS attributes. For details about TACACS+ attributes, see "TACACS Attribute-Value Pairs" at the Cisco website.

RADIUS is the most commonly used AAA protocol. HWTACACS and RADIUS have many similarities. For example, both HWTACACS and RADIUS use a client/server model, use the key mechanism to encrypt user information, and is extensible. The following compares HWTACACS and RADIUS.

• Data transmission mode

  RADIUS uses UDP as the transport protocol. The authentication and accounting port numbers are 1812 and 1813 respectively. HWTACACS uses TCP as the transport protocol. The authentication, authorization, and accounting port numbers are 49. UDP is a connectionless transport-layer protocol. Therefore, RADIUS uses the packet retransmission timeout mechanism to ensure that packets can be sent to the remote end. HWTACACS uses TCP, a connection-oriented transport-layer protocol, which provides more reliable network transmission.

• Packet encryption mode

  HWTACACS encrypts the entire body of the packet except the standard HWTACACS header. RADIUS encrypts only the password in an Access-Request packet. Other information, such as the user name, authorization information, and accounting information, is not encrypted. In a real-world network, encrypting the entire packet body is more conducive to communication security.

• Authentication and authorization

  RADIUS combines authentication and authorization, which cannot be separated because the Access-Accept packet sent by the RADIUS server contains authorization information. HWTACACS authentication, authorization, and accounting are independent of each other. Authentication and authorization can be performed on different servers. This makes HWTACACS more flexible in server deployment. For example, two HWTACACS servers A and B can be deployed to perform authentication and authorization respectively. In addition, during authorization, a successfully authenticated user does not need to be authenticated again because HWTACACS server A notifies HWTACACS server B that the user has been authenticated successfully.

• Device management

  RADIUS does not support command authorization. The commands available to users are determined only based on user privilege levels. HWTACACS supports command authorization. The commands available to users are determined by the AAA server and user privilege levels. Therefore, HWTACACS can flexibly control the commands available to users, facilitating device management.

• Protocol universality

  RADIUS is a standard protocol and is supported by almost all mainstream device vendors. More servers can be interconnected, and RADIUS is most widely used on live networks. HWTACACS is a proprietary protocol.

Compared with RADIUS, HWTACACS is more suitable for identity authentication of login users. In addition, HWTACACS has the following advantages in identity authentication of login users:

• Command authorization: In Figure 1-1, after a user logs in to the device through HWTACACS authentication, the device can authorize each command to be executed by the user based on the user privilege level through the HWTACACS server. The user can execute commands only when the authorization is successful.
  Figure 1-1 Command authorization

• Event reporting: In Figure 1-2, the device can send the following events to the HWTACACS server for archiving:
  • Command events: For example, users successfully execute commands on the device.
  • Connection events: For example, the device functioning as a Telnet client successfully logs in to or disconnects from another network device.
  • System-level events: For example, the device restarts after the reboot command is executed.
  Figure 1-2 Event reporting
  

The following describes how to configure HWTACACS.

1. Configure AAA schemes.

   In AAA schemes, set the authentication mode, authorization mode, and accounting mode to HWTACACS. HWTACACS authentication, authorization, and accounting functions are independent of each other, and can be configured on different servers. Typically, these functions are configured on the same server.

   • You are advised to configure local authentication and local authorization as backup authentication and backup authorization respectively, to ensure that users can still be authenticated and go online if the HWTACACS server is faulty. In this case, you need to configure a local user on the switch.
   • The switch does not support local accounting. If local authentication is specified in the authentication scheme, the policy for accounting-start failures must be set to "allowing users to go online if accounting-start fails".

   #
   aaa
    authentication-scheme tac1
     authentication-mode hwtacacs local  //Set the authentication mode to HWTACACS authentication and the backup authentication mode to local authentication.
    authorization-scheme tac1 
     authorization-mode hwtacacs local   //Set the authorization mode to HWTACACS authorization and the backup authorization mode to local authorization.
    accounting-scheme tac1 
     accounting-mode hwtacacs
     accounting start-fail online        //Allow users to go online if starting accounting fails.
   #  

2. Configure a server template.

   In the server template, specify the IP address, port number (49 by default), and shared key of the server connected to the switch. The configuration of the switch must be the same as that of the server.

   #
   hwtacacs-server template t1 
    hwtacacs-server authentication 10.1.1.2 
    hwtacacs-server authorization 10.1.1.2 
    hwtacacs-server accounting 10.1.1.2 
    hwtacacs-server shared-key cipher %^%#!~;V,L$O!#P7jD#k]wgL)ChiX74XR-)jn.:m={!<%^%#
   # 

3. Configure a local user. This step is required when local authentication is configured as backup authentication.
   Configure the user name, password, privilege level, and service type of the local user. The local user password is displayed in cipher text in the configuration file. The local user privilege level defaults to 0. The local user privilege level is in the range of 0 to 15.

   #
   aaa
    local-user user1 password irreversible-cipher $1a$~p]oP2VS:9$[._-/`)oN$5*l\2~IqR=g}g0%kay+H~vlLF/g<^A$ 
    local-user user1 privilege level 15
    local-user user1 service-type telnet 
   #

4. (Optional) Configure command authorization.

   If the undo authorization-cmd command is executed after the command authorization function is applied, the user will fail to execute any command except the quit command. In this case, the user needs to log in again.

   #
   aaa 
    authorization-scheme tac1 
     authorization-mode hwtacacs local
     authorization-cmd 15 hwtacacs local    //Configure the switch to perform command authorization for a user at the privilege level 15. If the server fails, the switch performs local authorization and executes commands based on only the user privilege level.
   # 

5. (Optional) Configure event reporting.

   aaa      
    recording-scheme sch0   
     recording-mode hwtacacs t1
    cmd recording-scheme sch0 
    outbound recording-scheme sch0
    system recording-scheme sch0

6. Configure a domain.

   Configure the domain to which the user belongs and bind the AAA scheme and server template to the domain.

   #
   aaa
    domain huawei 
     authentication-scheme tac1
     authorization-scheme tac1 
     accounting-scheme tac1
     hwtacacs-server t1
   # 

7. Configure the server. The following uses the Cisco ACS as an example.

   The server configuration procedure includes adding a device, adding a user, setting the user privilege level to 15, and configuring command authorization.

   In Reports and Activity > TACACS+ Administration, you can view the logs indicating the successful or failed command execution of all users.

For details about HWTACACS fundamentals, configurations, and configuration examples, see "AAA Configuration" in the S2720, S5700, S6700 V200R019C10 Configuration Guide - User Access and Authentication.