Which of the following method uses separate servers authentication, authorization, and accounting?

AAA supports configuring different authentication, authorization, and accounting methods for different types of users in an ISP domain. The NAS determines the ISP domain and access type of a user. The NAS also uses the methods configured for the access type in the domain to control the user's access.

AAA also supports configuring a set of default methods for an ISP domain. These default methods are applied to users for whom no AAA methods are configured.

Authentication methods

The device supports the following authentication methods:

• No authentication—This method trusts all users and does not perform authentication. For security purposes, do not use this method.

• Local authentication—The NAS authenticates users by itself, based on the locally configured user information including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the size of the storage space.

• Remote authentication—The NAS works with a RADIUS, LDAP, or HWTACACS server to authenticate users. The server manages user information in a centralized manner. Remote authentication provides high capacity, reliable, and centralized authentication services for multiple NASs. You can configure backup methods to be used when the remote server is not available.

Authorization methods

The device supports the following authorization methods:

• No authorization—The NAS performs no authorization exchange. The following default authorization information applies after users pass authentication:

  • Non-login users can access the network.

  • Login users obtain the level-0 user role. For more information about the level-0 user role, see RBAC configuration in Fundamentals Configuration Guide.

  • The working directory for FTP, SFTP, and SCP login users is the root directory of the NAS. However, the users do not have permission to access the root directory.

• Local authorization—The NAS performs authorization according to the user attributes locally configured for users.

• Remote authorization—The NAS works with a RADIUS, HWTACACS, or LDAP server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is included in the Access-Accept packet. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is included in the authorization response after successful authentication. You can configure backup methods to be used when the remote server is not available.

Accounting methods

The device supports the following accounting methods:

• No accounting—The NAS does not perform accounting for the users.

• Local accounting—Local accounting is implemented on the NAS. It counts and controls the number of concurrent users that use the same local user account, but does not provide statistics for charging.

• Remote accounting—The NAS works with a RADIUS server or HWTACACS server for accounting. You can configure backup methods to be used when the remote server is not available.

This chapter is from the book 

Authentication, Authorization, and Accounting (AAA) Overview

Using line and local authentication as well as privilege levels works fine for controlling access on a small number of devices. However, this solution does not scale well as the number of devices grows. It becomes cumbersome and introduces the risk of inconsistent access control configurations across devices. To help simplify configuration and maintain consistency as the number of Cisco IOS devices grows, you can use an authentication, authorization, and accounting (AAA) solution.

There are many AAA protocol implementations, but this chapter focuses on the two most popular of them: RADIUS and TACACS+.

With AAA, network devices use a centralized RADIUS or TACACS+ server to authenticate users, authorize the commands users can run on a device, and provide accounting information. As a fallback mechanism, it is recommended that you still use local authentication in case the AAA server becomes unavailable at some point.

Let’s briefly examine the AAA framework and how each part of it provides security functions:

• 
  Authentication: Authentication provides identity verification before access to a network device is granted. It is the process of verifying the identity of the person or device accessing a network device, and it is based on the username and password combination provided by the entity trying to gain access.

• 
  Authorization: Authorization provides access control. It is the process of assembling a set of attributes that describes what the user is authorized to perform. RADIUS and TACACS+ authorize users for specific rights by associating attribute/value (AV) pairs, which define the rights and the appropriate users.

• 
  Accounting: Accounting provides a method for collecting information, logging the information locally on a network device, and sending the information to an AAA server for billing, auditing, and reporting. The accounting feature tracks and maintains a log of every management session used for access. You can use this information to generate reports for troubleshooting and auditing purposes.

Some of the high-level benefits of using a remote AAA server over local AAA services on each network device individually are highlighted next:

• 
  Increased flexibility and control of access configuration

• 
  Scalability

• 
  Standardized authentication methods using RADIUS and TACACS+

• 
  Ease of setup, since RADIUS and TACACS+ may have already been deployed across the enterprise

• 
  More efficiency, since you can create user attributes once centrally and use them across multiple devices

Next, let’s touch on the high points of TACACS+ and RADIUS before looking at their configuration.

TACACS+ Overview

TACACS+ implementation provides for separate and modular authentication, authorization, and accounting facilities. It allows for a single access control server (referred to as the TACACS+ daemon) to provide authentication, authorization, and accounting to the network access server (NAS) independently. Typically, a client of a TACACS+ server is referred to as a NAS. A NAS may be a router, a switch, or an access point.

The TACACS+ protocol uses TCP port 49 for communication between the TACACS+ client (network device) and the TACACS+ server. A network administrator typically uses a workstation using Telnet, SSH, or the console to connect to a Cisco IOS device that needs to be managed. In this process, the TACACS+ client communicates with the TACACS+ server using the TACACS+ protocol. The TACACS+ protocol ensures confidentiality because all protocol exchanges between a TACACS+ client and a TACACS+ server are encrypted.

RADIUS Overview

The Cisco implementation of RADIUS provides for a RADIUS client that runs on a Cisco IOS device to send an authentication request to a central RADIUS server that contains all user authentication and network service access information. RADIUS can be used with other AAA security protocols, such as local username lookup and TACACS+.

There are two implementations of RADIUS: Cisco’s implementation and the industry-standard implementation. Cisco’s implementation uses UDP port 1645 for authentication and authorization and UDP port 1646 for accounting. The industry-standard implementation uses UDP port 1812 for authentication and authorization and UDP port 1813 for accounting. The industry-standard implementation of the RADIUS protocol provides the distinction of working in a multi-vendor environment. Network devices from different vendors can connect to the same RADIUS server for AAA services. RADIUS can also be more convenient for AAA than TACACS+ since some organizations may already have it deployed.

As it relates to the privilege levels examined earlier in the chapter, TACACS+ and RADIUS can also be implemented when using AAA. For example, TACACS+ provides two ways to control the authorization of the network device commands on a per-user or per-group basis. One way is to assign privilege levels to commands and have the router verify with the TACACS+ server whether the user is authorized at the specified privilege level. Another way is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the allowed commands.

Cisco’s TACACS+ and RADIUS implementations used to occur through the implementation of Cisco Secure Access Control Server (ACS), where RADIUS was used for network access control and TACACS+ was used for network devices access control. However, Cisco Identity Services Engine (ISE) is now the preferred implementation for AAA servers to support both TACACS+ and RADIUS protocols.

AAA Configuration for Network Devices

In this section, you will see how both TACACS+ and RADIUS are configured from a Cisco IOS device. This section does not cover the configuration of a TACACS+ or RADIUS server because that is beyond the scope of this chapter.

There are two parts to configuring TACACS+ support: a TACACS+ server (for example, Cisco ISE) and a Cisco IOS device. At a high level, to configure a Cisco IOS device to support TACACS+, the following steps are involved:

1. Create a local user that will serve as the fallback if the TACACS+ server is not available or if you accidentally lock yourself out after enabling the AAA command. As highlighted previously, this is done with the command username username privilege 15 algorithm-type {md5 | sha256 | scrypt} secret password.

2. Enable the AAA function with the aaa new-model global configuration command.

3. Add a TACACS+ server.

4. Define the method lists for TACACS+ authentication by using the aaa authentication global configuration command.

5. Use the line and interface commands to apply the defined method lists to various interfaces.

6. If needed, use the aaa authorization global command to configure authorization for the device. Unlike with authentication, which can be configured per line or per interface, authorization is configured globally for an entire device.

7. If needed, use the aaa accounting command to enable accounting for TACACS+ connections.

Example 6.10 shows how to configure an IOS device with TACACS+ for device access control based on these steps. This example demonstrates basic authentication, authorization, and accounting configuration. Once the command aaa-new model is configured, there is no line authentication anymore on the vty lines as the default login method becomes AAA. The console port defaults to no authentication. If you were to disable this with the no aaa new-model command afterward, the login method would switch back to line authentication. However, you would not see login local under vty line; you would see just login (meaning just the line password will be checked, and not the local user database that is configured locally on the router).

EXAMPLE 6.10 Configuring TACACS+

R1#
R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
!Authentication setup
!First we create a fallback user account
R1(config)# username fallback privilege 15 algorithm-type scrypt
secret Cisco123
R1(config)# aaa new-model
R1(config)# tacacs server TACACSSERVER1
R1(config-server-tacacs)# address ipv4 100.1.1.2
R1(config-server-tacacs)# key Cisco123
R1(config-server-tacacs)# exit
R1(config)# aaa group server tacacs+ TACACSGROUP1
R1(config-sg-tacacs+)# server name TACACSSERVER1
R1(config)# aaa authentication login default group TACACSGROUP1 local
!the default method list automatically applies to all lines, except
the ones that have a named method list explicitly define or in other
words, it gets applied unless a more specific named method list is
defined.
!we can also specify on the vty lines the login authentication METH-
ODLIST1 command then tacacs+ TACACSGROUP1 will be used as the primary
authentication method and the local user database is set as the backup
R1(config)# line vty 0 4
R1(config-line)# login authentication methodlist1
!Authorization setup
!Next, for authorization we create a method list TACACSAUTH1
!if-authentication option allows a user who is authenticated to be 
placed in EXEC mode
R1(config)# aaa authorization exec TACACSAUTH1 group TACACSGROUP1
local if-authenticated
R1(config)# aaa authorization commands 15 TACACSAUTH1 group TACACS
GROUP1 local
!The config-commands command indicates that the server must return 
permission to use any router configuration command
R1(config)# aaa authorization config-commands
R1(config)# aaa authorization console
!The TACACSAUTH1 method list is applied to the vty lines for both EXEC
and level 15 command access
R1(config)# line vty 0 4
R1(config-line)# authorization exec TACACSAUTH1
R1(config-line)# authorization commands 15 TACACSAUTH1
R1(config-line)# exit
R1(config)#
!Accounting setup
 !Next, for accounting we create a method list TACACSACC1
 !User EXEC sessions will be recorded as they start and stop, along 
with user information
R1(config)# aaa accounting exec TACACSACC1 start-stop group 
TACACSGROUP1
!commands that are entered while a user is in privilege level 15 
(enable mode) will be recorded
R1(config)# aaa accounting commands 15 TACACSACC1 start-stop group 
TACSRVGROUP1
!The TACACSACC1 method list is applied to the vty lines for EXEC and 
level 15 commands
R1(config)# line vty 0 4
R1(config-line)# accounting exec TACACSACC1
R1(config-line)# accounting commands 15 TACACSACC1
R1(config-line)# end
R1#

The AAA server also needs to be configured with the AAA client information (that is, the hostname, IP address, and key), the login credentials for the users, and the commands the users are authorized to execute on the device.

At a high level, to configure a Cisco IOS device to support RADIUS, the following steps are involved:

1. Enable AAA with the aaa new-model global configuration command.

2. Define the RADIUS server and specify the IP address and key.

3. Add the RADIUS server to a server group.

4. Define method lists for RADIUS authentication by using the aaa authentication login method-list global configuration command.

5. Create a named method list and add a RADIUS server group as the ­primary and local database as backup by using the aaa authentication login command.

6. Use the line and interface commands to enable the defined method lists to be used. For example, Example 6.11 specifies the login authentication method-list command on the vty lines, and then the RADIUS server group will be used as the primary authentication method, and the local user database is set as the backup.

Example 6.11 shows the configuration of an IOS device with RADIUS for device access control based on these steps (which are nearly identical to the steps for TACACS+ configuration). This example demonstrates basic authentication configuration.

EXAMPLE 6.11 Configuring RADIUS

R1#
R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# aaa new-model
R1(config)# radius server RADIUSSERVER1
R1(config-radius-server)# address ipv4 100.1.1.2
R1(config-radius-server)# key Cisco123
R1(config-radius-server)# exit
R1(config)# aaa group server radius RADIUSGROUP1
R1(config-sg-radius)# server name RADIUSSERVER1
R1(config-sg-radius)# exit
R1(config)# aaa authentication login METHODLIST2 group RADIUSGROUP1 
local
!the default method list automatically applies to all lines, except 
the ones that have a named method list explicitly define or in other 
words, it gets applied unless a more specific named method list is 
defined.
!we can also specify on the vty lines the login authentication METHOD-
LIST2 command then RADIUSGROUP1 will be used as the primary authenti-
cation method and the local user database is set as the backup
R1(config-line)# line vty 0 4
R1(config-line)# login authentication METHODLIST2
R1(config-line)# end
R1#

Which of the following protocols provide authentication, authorization, and accounting services?

Which server can act as a centralized authentication server in your network?

What is authentication, authorization, and accounting quizlet?

What does a remote access server use for authorization quizlet?