10.2.3 Authentication using RADIUS/ TACACS+

(a) When end-by-reject is not set

The following explains how an authentication service is selected when end-by-reject is not set. If authentication fails when using the first specified method when end-by-reject is not set, authentication can be performed using the next specified method regardless of the reason of failure.

As an example, the figure below shows the sequence in which authentication is performed when RADIUS, TACACS+, and individual login security methods are specified and performed in that order. The authentication results are as follows: The RADIUS server cannot communicate, the TACACS+ server denies authentication, and authentication succeeds through the login security function.

In this figure, the user accesses the Switch via Telnet from a remote operation terminal, and the Switch requests the RADIUS server to perform authentication. If the RADIUS authentication fails due to a communication failure, the Switch requests the TACACS+ server to perform authentication. If TACACS+ authentication fails because the TACACS+ server denied the request, the Switch performs authentication using the local login security functions. At this point, authentication is successful and the user is able to log in to the Switch.

(b) When end-by-reject is set

The following explains how an authentication service is selected when end-by-reject is set. If authentication fails when using the first specified method when end-by-reject is set, authentication is not performed using the next specified method. The entire authentication process is terminated at the first denial and is treated as a failure. The next authentication is performed only when authentication failed due to an abnormality such as communication failure.

As an example, the figure below shows the sequence in which authentication is performed when RADIUS, TACACS+, and individual login security methods are specified and performed in that order. The authentication results are as follows: The RADIUS server cannot communicate, and the TACACS+ server denies authentication.

In this figure, the user accesses the Switch via Telnet from a remote operation terminal, and the Switch requests the RADIUS server to perform authentication. If the RADIUS authentication fails due to a communication failure, the Switch requests the TACACS+ server to perform authentication. The entire authentication process fails when authentication is denied by the TACACS+ server. The login security functionality of this Switch that is specified as the next method is not performed. As a result, the user fails to log in to the Switch.

(a) When using login authentication

Register the user name and password with the RADIUS or TACACS+ server. A user name can be registered in either of two ways:

• User name already registered in the Switch by the adduser command

  Login processing is based on the user information registered in the Switch.

• Unregistered user name

  Login processing is based on the following common user information:

  • User ID: remote_user

  • Home directory: /usr/home/remote_user

Note the following when an unregistered user logs in:

• File management

  All created files are managed under the remote_user ID, which means that other users will be able to read and write to them. Manage files carefully, for example by storing important files outside the network by FTP or other means.

(b) When using authorization when changing to administrator mode (enable command)

Register the following user information for changing to administrator mode (by the enable command):

• User name

  This Switch sends the user names shown in the table below to the server as user name attributes. The user names to be sent can be changed using configuration commands. Register the corresponding user names with the server.

  Table 10-9: User name attributes to be set

  Command name	User name
  	RADIUS authentication	TACACS+ authentication
  Not set	admin	admin
  aaa authentication enable attribute-user-per-method	$enab15$	Login user name

• Privilege level

  The privilege level is fixed at 15.

However, some servers use specific names (e.g. $enab15$) regardless of the sent user name attributes, and in some cases, privilege level registration is not necessary. For details, see your server documentation.