TACACS+

What is TACACS+?

TACACS+ stands for Terminal Access Controller Access Control Server and is a security protocol utilized in the AAA framework to supply centralized authentication for users who want to achieve access to the network.

If one administrator desires to access a hundred routers and therefore the native info of the device is utilized for username and authentication then the administrator must create a constant user account at completely different times. Also, if he desires to retain a unique username and authentication for the devices then he must manually modify the authentication for the devices. Naturally, it’s a busy task.

TACACS+ permits productive transmission of AAA info among NASs and a central server. The division of the AAA purposes is a fundamental characteristic of the TACACS+:

• Authentication— Regulates who a client is, then decides whether that client should be provided access to the network. The foremost purpose is to stop intruders from arriving in your networks. Authentication utilizes a database of clients and their passwords(credentials).
• Authorization— Regulates what an authenticated client is permitted to do. Authorization offers the network executive the potential to restrict network facilities to other clients. Also, the network executive can restrict the utilization of particular instructions to different clients. Authorization cannot happen without authentication.
• Accounting— Routes what a client did and when it was finished. Accounting can be utilized for an audit trail or for billing for attaching time or sources utilized. Accounting can happen autonomously with authentication and authorization.

History

TACACS was originally developed in 1984 by BBN, later referred to as BBN Technologies, for the administration of ARPANET and MILNET, which ran unclassified network traffic for DARPA at the time and would later evolve into the U.S. Department of Defense's NIPRNet. Originally designed as a method to alter authentication – permitting somebody who was already logged into one host within the network to attach to a different one on a constant network while not having to re-authenticate – it had been 1st formally delineated by BBN's Brian Anderson TAC Access system Protocols, BBN technical school memoranda CC-0045 with minor TELNET double login rejection amendment in Gregorian calendar month 1984 in IETF RFC 927 Cisco Systems began supporting TACACS in its networking merchandise within the late nineteen-eighties, eventually adding many extensions to the protocol. In 1990, Cisco's extensions on prime of TACACS became a proprietary protocol known as Extended TACACS (XTACACS). Though TACACS and XTACACS don't seem to be open standards, Craig Finseth of the University of American state, with Cisco's help, printed an outline of the protocols in 1993 in IETF RFC 1492 for informational functions.

Features of TACACS+

• Cisco evolved a protocol for the AAA framework which basically can be utilized among the Cisco device and Cisco ACS server.
• TACACS+ utilized the Transmission Control Protocol as a transmission protocol.
• TACACS+ utilizes Transmission Control Protocol port number 49.
• TACACS+ the system and ACS server are exploiting TACACS+ then all the AAA messages interchanged among them are encrypted.
• TACACS+ distinct AAA into separate elements which are authentication, authorization, and accounting are unrelated.
• TACACS+ supplies larger granular management than RADIUS because the instructions that are licensed to be utilized by the user can be nominal.
• TACACS+ produces accounting facilities that are smaller and more extensive than RADIUS.

Working of TACACS+

The customer of the TACACS+ is termed Network Access Device (NAD) or Network Access Server (NAS). Network Access Device can reach out to the TACACS+ server to gain a username prompt through the CONTINUE communication. The customer then fills in a username and the Network Access Device once again approaches the TACACS+ server to acquire a password prompt showing the password instantly to the customer, the user fills in a password, and the password is then delivered to the TACACS+ server.

The server will respond with one in all the subsequent reply communication:

• If the login credentials filled are legit then the TACACS+ server can answer with an "ACCEPT" notification.
• If the login credentials filled are legit then the TACACS+ server can answer with a "REJECT" notification.
• If the connection between the TACACS+ server and NAS or TACACS+ server is not operating properly then it will answer with an "ERROR" notification.
• If TACACS+ authorization is needed, the TACACS+ server is once more contacted and it returns an ACCEPT or REJECT authorization sent back. If the ACCEPT message is reverted back, it holds attributes that are used to regulate services that a customer is permitted to do.

For accounting, the customer can send a REQUEST communication to the TACACS+ server for which the server answers with a RESPONSE notification saying that the record is gained.

TACACS+ Authentication

After you get to know the TACACS+ daemon and explain a related TACACS+ cryptography key, you need to outline methodology lists for TACACS+ authentication. As a result of TACACS+ authentication being operated via AAA, you would like to issue the AAA confirmation instruction, identifying TACACS+ as the authentication methodology. For additional info, seek advice from the section “Configuring Authentication.”

The given example shows a way to pattern TACACS+ as the safety treaty for PPP (Point-to-Point Protocol) authentication:

The lines within the earlier selected configuration are outlined as follows:

• The AAA new-model instruction allows the AAA security facilities.
• The AAA authentication instruction explains a technique list, “test,” to be utilized on serial interfaces running PPP. The keyword cluster tacacs+ implies that authentication is done through TACACS+. If TACACS+ gives back an ERROR of some type throughout authentication, the keyword native indicates that authentication is tried or attempted using the native information on the network access server.
• The tacacs-server host instruction recognizes the TACACS+ daemon as possessing an IP address of 10.1.2.3. The tacacs-server key instruction explains the split encryption key to be “go away.”
• The interface instruction chooses the line, and therefore the PPP authentication instruction appeals to take a look at the method list to the present line.

The successive example manifests a way to configure TACACS+ because of the safety protocol for PPP confirmation, however, rather than the “test” methodology list, the “default” methodology list is utilized.

The lines within the previous sample configuration are outlined as follows:

• The AAA new-model instruction allows the AAA security solutions.
• The AAA authentication instruction explains a technique list, “default,” to be utilized on serial intersections running PPP. The keyword default implies that PPP documentation is concerned about defaulting to all intersections. The if-needed keyword implies that if the customer has been authenticated by undergoing the ASCII login procedure, then PPP authentication is not mandatory and can be jumped. If authentication is required, the keyword cluster TACACS+ implies that authentication is done through TACACS+. If TACACS+ gives back an ERROR of some type throughout authentication, the keyword native specifies that authentication will be aimed at victimizing the native information on the network access server.

The tacacs-server host instruction recognized the TACACS+ daemon as holding an IP address of 10.1.2.3. The tacacs-server key instruction elaborates the shared cryptography key to be “go away.”

The interrelated instruction selects the line, and therefore the ppp authentication instruction applies the by-default methodology list to this present line.

How to Configure TACACS+?

The following explains a way to configure TACACS+.

1. Configure AAA strategy.

In AAA schemes, set the authentication mode, authorization mode, and accounting mode to TACACS. TACACS authentication, authorization, and accounting functions are independent of one another and might be organized on totally different servers. Typically, these features are organized on the equivalent server.

2. Customize a server template.

In the server template, identify the IP address, port range 49 by default, and the split key of the server linked to the switch. The configuration of the switch should be the same equivalent as that of the server.

3. Customize a native user.

This step is needed once general authentication is organized as backup authentication.

set up the user name, password, advantage level, and different types of the local client. The local client password is shown in cipher text within the configuration file. The native user's right level reverts to 0. The local client's benefit level is on a scale of 0 to 15.

4. (Optional) Configure command authorization

5. (Optional) Configure event reporting.

6. Configure a domain. Compose the domain to which the customer includes and bind the AAA theme and server template to the given domain.

7. Customize the server. The subsequent uses the Cisco ACS as an illustration.

The server configuration policy involves putting a system, adding a customer, setting the customer advantages level to 15, and configuring command authorization.

TACACS/TACACS+ Terminology

• Client - The shopper is any device (often a Network Access Server) that gives access services.

• Server - The server receives TACACS+ protocol requests, and replies consistent with its business model.

• TACACS/TACACS+ Authentication- TACACS Authentication is that the action of a determinant UN agency a user (or entity) is. Authentication will take several forms. An ancient authentication utilizes a reputation and a hard and fast countersign. However, fastened passwords have limitations, chiefly within the space of security. Several trendy authentication mechanisms utilize "one-time" passwords or challenge-response questions. TACACS+ is intended to support all of those and be powerful enough to handle any future mechanisms. Authentication typically takes place once the user initially logs in to a machine or requests a service from it.

• TACACS/TACACS+ Authorization - Authorization is the action of determining what a user is allowed to try and do. Typically authentication precedes authorization, but again, this is often not needed. and authorization requests could indicate that the user isn't documented (we do not know who they are). TACACS+ authorization doesn't simply offer affirmative or no answers, however, it's going to conjointly customize the service for the actual user. The TACACS+ server would possibly reply to these requests by permitting the service, however putting a time restriction on the login shell, or by requiring scientific discipline access lists on the PPP affiliation.

• TACACS/TACACS+ Accounting - Accounting is often the third action once authentication and authorization. But again, neither authentication nor authorization is needed. Accounting is the step of monitoring what a client is doing, and/or has been done already. TACACS+ Accounting will serve 2 purposes: it's going to be used as an Associate in Nursing auditing tool for security services. it's going to be wont to account for services used, like in an exceeding request setting.

Difference between HWTACACS and TACACS+.

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

HWTACACS and TACACS+ outline an equivalent packet structure and kind. The biggest distinction between HWTACACS and TACACS+ is that the meanings or kinds of the attributes in authorization and accounting packet area units are completely different. For instance, once a Huawei S series switch connects to a TACACS+ server to manifest Telnet users, the fundamental authentication, user privilege level authorization, and command authorization functions are enforced usually. If there are unit further necessities, question HWTACACS, and TACACS+ attributes. These necessities are met once each HWTACACS and TACACS+ attributes area unit is supported. Table 1-1 lists HWTACACS attributes. For details concerning TACACS+ attributes, see "TACACS+ Attribute-Value Pairs" on the Cisco website.

Difference between RADIUS and TACACS

RADIUS (Remote Access Dial In User Service) is the most ordinarily used AAA protocol. HWTACACS and RADIUS have several similarities. As an example, each HWTACACS and RADIUS uses a client/server model, uses the key mechanism to encode user info, and is extensible. Then compare HWTACACS and RADIUS.

• Data transmission mode RADIUS uses UDP because of the transport protocol. The authentication and accounting port numbers square measure 1812 and 1813 severally. HWTACACS uses protocol because of the transport protocol. The authentication, authorization, and accounting port numbers square measure forty-nine. UDP may be a connectionless transport-layer protocol. Therefore, RADIUS uses the packet retransmission timeout mechanism to make sure that packets are often sent to the remote finish. HWTACACS uses the protocol, a connection-oriented transport-layer protocol, that provides a lot of reliable network transmission.

• Packet coding mode HWTACACS encrypts the whole body of the packet except the quality HWTACACS header. RADIUS encrypts the countersign in the associated Access-Request packet. Different info, like the user name, authorization info, and accounting info, isn't encrypted. In an exceedingly real-world network, encrypting the whole packet body is a lot of tributary to communication security.

• Authentication and authorization RADIUS combines authentication and authorization that can't be separated as a result of the Access-Accept packet sent by the RADIUS server containing authorization info. HWTACACS authentication, authorization, and accounting square measure freelance of every different. Authentication and authorization are often performed on completely different servers. This makes HWTACACS a lot more versatile in server preparation. As an example, 2 HWTACACS servers A and B are often deployed to perform authentication and authorization severally. Additionally, throughout authorization, a genuine user doesn't get to be genuine once more as a result of HWTACACS server A notifying HWTACACS server B that the user has been genuine with success.

• Device management RADIUS doesn't support command authorization. The commands are accessible to users square measure determined solely by supported user privilege levels. HWTACACS supports command authorization. The commands are accessible to users square measure determined by the AAA server and user privilege levels. Therefore, HWTACACS will flexibly manage the commands accessible to users, facilitating device management.

• Protocol catholicity RADIUS may be a normal protocol and is supported by the majority of device vendors. A lot of servers are often interconnected, and RADIUS is most generally used on live networks. HWTACACS may be a proprietary protocol.

Advantages and Disadvantages of TACACS+

Advantages of TACACS+

• Provides bigger granular management than RADIUS. TACACS+ permits a network administrator to outline what commands a user might run.
• All the AAA packets are encrypted instead of simply passwords (in the case of RADIUS).
• TACACS+ uses TCP rather than UDP. TCP protocol guarantees communication between the consumer and server.

Disadvantages of TACACS+

• As it is Cisco proprietary, so it may be used between the Cisco devices solely. TACAS+ is associated with open commonplace RADIUS
• Less in-depth support for accounting than RADIUS.