Device security using Cisco IOS AAA with TACACS+ and RADIUS
The device security plays an important role in the Cisco internet service provider. To facilitate the network or system without without any difficulties or trouble, it is very essential to protect it with proper security measures and device. It is the very essential one for the network administrators and all network professional to be through with the device security. This section will guide you how to secure the device by using the AAA with the TACACS+ and RADIUS.
2.2.a AAA with TACACS+ and RADIUS
The AAA is the way to control who is permitted to access the network implies authenticate, and what they do when they are there implies authorize and what actions they perform when accessing a network to audit implies the accounting. When the AAA accounting is enabled, a network access server will report user activity to the RADIUS or TACACS+.
RADIUS: The RADIUS stands for Remote authentication dial in user service. It is the networking protocol, which gives centralized authentication, authorization and accounting management for customers that connects and use the network service. The RADIUS is the client or server protocol which runs in an application layer by using the UDP as the transport. The VPN server, Remote access server, NAS- network access server, and a network switch with the port based authentication are the gateways which control access to a network and also all have the RADIUS client components that communicate with a RADIUS server. The RADIUS server uses an AAA concept to manage the network access. RADIUS is the fully open protocol. The Csico supports the RADIUS under the AAA security paradigm. It can be used by the other AAA security protocol like TACACS+, local username lookup and Kerberos.
The AAA client sends the user information to an AAA server through RADIUS protocol and RADIUS server will respond with the entire information required for an AAA client to offer the service and connectivity to an end user. An AAA client can act in response to reply that it gets from a RADIUS server. For the network authentication, the shared secret key will authenticate messages in between the RADIUS/AAA server and an AAA client. Then the shared secret key can never sent across the wire actually hence the key integrity is maintained. When the RADIUS authenticated the users, then numerous authentications ways can also be used. The RADIUS supports the authentication through point to point protocol CHAP and point to point PAP and others.
The RADIUS is the extensible protocol, which allows vendors the capability to add the new attribute value without producing the issue for the existing attribute value. The major difference between the RADIUS and TACACS+ is that the RADIUS can not separate the authentication as well as authorization. The RADIUS also gives for better accounting. The RADIUS will operate under a UDP protocol. It uses the ports 1812 and 1645 for the authentication and 1813 and 1646 for the accounting. The ports like 1813 and 1812 has seen in the newer RADIUS and its implementation. Use of the RADIUS port1645 in the before implementation conflicts with a datametric service. Hence officially assigned port for this is 1812. Normally, this RADIUS protocol is referred to be the connectionless service. Problems related to the server availability, timeouts and retransmission are handled and managed by a RADIUS enabled device instead of the transmission protocol. Hence, this type of functionality will differ from the TACACS+, while reliability in a protocol is dependent on a TCP protocol.
Given below is the process which is used in the RADIUS managed login as follows:
- The user login generates the query
- The corresponding response is returned by a server.
An access request packet comprises the encrypted password, username, IP addresses of the AAA port and client. The format of a request offers information on session type that users like to initiate. The encryption in the RADIUS has differed from that of the TACACS+, since the RADIUS only encrypts the passwords and the remaining sent in the clear text.
When the AAA server running the RADIUS gets the access-request from an AAA client, then it searches the database for a username listed. In case, the username cannot exist in a database, either the default profiles are loaded or a RADIUS server sends the access-reject message immediately. In case, the password and username are perfectly correct, then the RADIUS server can return the access-accept response such as a list of attribute value pairs which describe a parameter which has to be used. The typical parameters also include the service type, access list to apply, IP address to assign a user, protocol type or static routes to install in an AAA client routing table. Below diagram will get you understand about the RADIUS exchange.
The authorizations within the RADIUS is done in the conjunction with the authentication. As the server returns the access-accept message, it includes a list of the AV pairs which the users are authorized for.
The RADIUS accountings are performed by simply sending the messages at the start as well as the stop of the session. The messages also include information on the session. The information may include the time, bytes, packets and much more. The message is sent by using the UDP port1813. The process of accounting is in the below figure:
TACACS+: The TACACS+ stands for terminal access controller access control system plus. It is the protocol which is developed by Cisco. However, it is derived from the TACACS, this TACACS+ is the separate protocol which handles AAA service. It is entirely a new protocol which is not compatible with the predecessors, XTACACS and TACACS. The TACACS+perform very reliable between the AAA client and AAA server. It also performs the authentication as well as encryption of all the messages between the AAA client and AAA server.
The TACACS+ communication in between a NAS and the AAA client based on an TCP protocol and also gives the reliable delivery mechanism to an AAA messaging. The TACACS+ uses the TCP port49 as well as create the session to facilitates messaging in an AAA exchange. Along with the acknowledgements offered within the TCP, the TACACS+ has the capability via the inherent functionality of a TCP protocol, to adapt to bandwidth and congestion. The TACACS+ has the capability to determine when the AAA servers are not available using TCP resets to alert an AAA client of the server communication problem immediately. This kind of functionality is not at all possible with the RADIUS protocol, since it uses a UDP for the segment delivery. The TACACS+ ID also defines the 12 byte header which appears all the TACACS+ packets. This type of header is sent in the clear text format mostly.
The most best feature under the TACACS+ opposed with the RADIUS is the encryption of all the packets. The encryption is then sent between the AAA server and AAA client running a TACACS+ daemon. It is not confused with the user data encryption. There are 3 possible activities can be take place during the TACACS+operation. Here, the first operation is authentication. It is done to identify the user clearly. Then the second operation is the authorization which can be done only once the user is identified. Hence, it is important to authenticate before authorizing. Then the third operation is the accounting. The process of accounting maintains track of action performed. Here, these 3 processes are independent of one another.
The above figure shows the TACACS+ messaging and the below diagram implies about the TACACS+ authorization in short as follows:
To facilitate the authorization in the TACACS+, 2 types of messages are used. Here, the first message is the authorization request and the other one is an authorization response. Here, the response can source from a AAA server and the request can source from a AAA client.
Given below is the basic accounting figure.
The accounting functionality in the TACACS+ is very similar to that of the authorization. The accounting is done by sending the record to a AAA server. In that, each record includes the AV pair for accounting. There are 3 types of records which can be sent to a AAA server, such as stop record, start record and continue record. The start record is the one indicated when the service starts and also contains the information which was included in, an authorization process and specific information to an account. The stop record means when the service is terminated or about to stop and it includes the information which was added in the process of authorization and the certain information to an account. The continue record is also known as the watchdog. It is sent when the service is in progress and also allows an AAA client to offer updated information to a AAA server. It includes the information which was added in the process of authorization and the certain information to an account.
2.2.b Local privilege authorization fallback
A local database can also act as the fallback method for a variety of functions. So this type of behavior is proposed to assist you prevent from the accidental lockout from an ASA. When the user login, a server in a group is accessed one at the time, starting with a 1st server, which you indicate in a configuration, until the server responds, suppose all the servers in a group becomes unavailable, then an ASA tries a local database if configured it as the fallback method. Suppose you do not have any fallback method, an ASA will continue to try a AAA server. For the users who require fallback support, it is recommended that the username and password in a local database must match with the username and password on an AAA server. This type practice gives transparent fallback support. Since, a user may not find out whether the AAA server or a local database is given a service, by using the password and username on the AAA server, which are different than the password and username in a local database implies that the user is not very specific which password and username has to be given. Suppose you turn on the command authorization by using the local database, then an ASA refers to a user privilege level to find out which command is available. Or else, a privilege is not all generally used. As default, all the commands are either privilege level 15 or level 0.
The local database supports the below fallback functions as follows:
Suppose the TACACS+ server in a group becomes unavailable, then a local database is mainly used to authorize the commands depends on the privilege level.
The VPN authorization and authentication are mostly supported to enable the remote access to an ASA suppose the AAA server that generally supports the VPN services becomes unavailable. When the VPN client of the administrator indicates the tunnel group configured mostly to fallback to a local database, then a VPN tunnel may be accomplished, although a AAA server becomes unavailable, offered that a local database is configured along with an essential attribute.
The RADIUS and TACACS+ offer a way to centrally validate the users attempting to acquire the access to the router or the access server. TACACS+ is the protocol implemented by the Cisco system to facilitate a AAA model in the Cisco devices. It separates each function of the AAA. RADIUS is the IETF standardized protocol which is also implemented in the Cisco devices to facilitate a AAA model communication between the AAA client and AAA server. The RADIUS uses the UDP as the transport protocol and also relies on the protocol to resend as well as recover from the missing or lost data. It will not separate the authentication and authorization. It offers complete accounting abilities than the TACACS+. To implement the secure network by using 6the AAA, then you will face some sort of doubt to select the protocols that proceed with the things by keeping the functions of the protocol based on your needs. The local privileged authorization fallback will get you understand the fallback method.