10.2.4 RADIUS/TACACS+/local command authorization

(1) Command Approval Overview

You can restrict the types of operation commands available to a login user who has been authenticated by a RADIUS server, TACACS+ server, or local password. This is known as command authorization. The operation commands that the user is allowed to use are controlled according to a command class or command lists obtained from the RADIUS or TACACS+ server or set in the local configuration. Operation commands that the user is not allowed to use do not appear among the character strings presented by command line completion. When a partially entered operation command contains a parameter with a value or character string, such as <option> or <Host Name>, the parameter part does not appear among the displayed entry completion strings.

When command authorization is configured in the aaa configuration entries and RADIUS or TACACS+ authorization is specified, the command lists for the user are retrieved from the server concurrently with login authentication. If local command authorization is specified, the command lists set in the configuration entries are obtained concurrently with the login authentication. The Switch permits or denies operation commands entered by the login user according to these command lists.

When a user executes a telnet from a terminal to the Switch in the "Diagram 10-15 RADIUS/TACACS+ Sequence of Command Authorization by Server," the Switch authenticates and requests command authorization from the Switch to RADIUS/TACACS + server. Authentication succeeds, the associated command lists are retrieved from the server, and the user logs in to the Switch.

Local authentication is performed when a user executes a telnet from a terminal to the Switch in Figure 10-16: Sequence of local command authorization. Authentication succeeds, the associated command lists are obtained from the local configuration, and the user logs in to the Switch.

After login, the user can execute operation commands such as show interfaces on the Switch. The reload operation command cannot be executed, however, because it is included in the unauthorized command list.

Notes

Any changes you make to a command list on the RADIUS or TACACS+ server, or to a locally configured command list, apply after the next login authentication.

(2) RADIUS/TACACS +/Local Command Authorization Setting

To use RADIUS or TACACS+ command authorization, set up a RADIUS or TACACS+ server and the Switch as follows:

1. Decide your policies for restricting command execution.

   Decide for each user which operation commands to permit and which to restrict.

2. Create command lists.

   In addition to specifying a command class, you can set up separate lists of authorized commands and unauthorized commands.

3. Set up a RADIUS or TACACS+ server.

   On the RADIUS or TACACS+ remote authentication server, perform the settings for authorizing commands based on your command restriction policies.

4. Set up remote authentication on the Switch.

   Configure RADIUS or TACACS+ authentication and complete the aaa configuration tasks.

5. Test the command authorization to make sure it works.

   Log in to the Switch from a remote operation terminal that is set up for RADIUS or TACACS+ authentication, and make sure that entered commands are permitted or denied correctly.

To use local command authorization, set up the Switch as follows:

1. Decide your policies for restricting command execution.

   Decide for each user which operation commands to permit and which to restrict.

2. Create command lists.

   You can specify a command class, or you can enter authorized and unauthorized commands in separate command lists. Configure each command list based on your command restriction policies.

   There is no need to create any command lists if you are using command classes only.

3. Assign a command class or command lists to each user.

   Enter the username configuration command for each user, specifying the appropriate command class or command lists.

   When you have finished, complete the aaa configuration tasks.

4. Test the command authorization to make sure it works.

   Log in to the Switch by local authentication, and check that commands are permitted or denied correctly.

(3) Command restriction policy decisions

Decide for each user which operation commands to permit and which to restrict. This means that each user, once logged in, will be allowed to use some commands but not others. The policy is set in (5) RADIUS/TACACS +/Local command authorization setting.

A command restriction policy applies only to operation commands. It does not apply to undocumented debugging commands (such as the ps command) which are always unauthorized.(If you ever need to set permission for debugging commands, specify the root unrestricted command class described below.) The logout, exit, quit, disable, end, set terminal, show whoami, and who am i commands are always permitted.

The following policies are pre-defined in the Switch. By selecting one of these standard command classes, you can set the command restrictions associated with that class.

In addition to specifying a command class, you can specify an authorized command list and unauthorized command list.

(4) Command list specification method

In addition to specifying a command class, you can set up separate lists of authorized commands and unauthorized commands. When entering commands in each list, be aware of any spaces required in the command strings and separate each command with a comma (,). To create a command list for local command authorization, specify each command in a separate commands exec configuration command. The entered commands, linked with commas, are used on the Switch as a command list.

It is determined whether any of the command strings in the command lists match the initial character string of the command entered by the user (match beginning). As a special character, you can specify all in a command list, which means all operation commands.

When an entered command matches commands in both the authorized command list and unauthorized command list, the resultant action is determined by the matched command that has the greater number of characters (where all counts as one character). If both command lists contain the same command string, the input command is taken to be authorized.

If the command class and the permit/restrict command list are specified at the same time, the command list specified for each command class (corresponding to the command list enclosed in " in Table 10-10 Command Class List) and the permit/restrict command list are combined to make a judgment. Also, if you specify the root command class, this will invalidate the authorized/unauthorized command class settings, allowing the user to execute all commands including undocumented debugging commands (such as the ps command).

Example 1 to 7 shows the commands that are permitted or restricted by the Switch when a list of commands is set.

Example 1

If you set only an authorized command list, the user is authorized to execute only the commands in that list.

Table 10-11: Command list example 1

Command list	Input by user	Judgment
Authorized command list = "show ,ping" Unauthorized command list: None set	show ip arp	Allow
	ping 10.10.10.10	Allow
	reload	Deny

(Example 2)

If an entered command matches commands in both the authorized command list and unauthorized command list, the judgment is determined by the matched command that has the greater number of characters (where all counts as one character).

Table 10-12: Command list example 2

Command list	Input by user	Judgment
Authorized command list = "show" Restricted command list = "show ip"	show system	Allow
	show ip arp	Deny

(Example 3)

If you set both authorized and unauthorized command lists, entered commands that match neither list are taken to be authorized.

Table 10-13: Command list example 3

Command list	Input by user	Judgment
Authorized command list = "show" Restricted command list = "reload"	ping 10.10.10.10	Allow
	reload	Deny

(Example 4)

If the same command string appears in both the authorized and unauthorized command lists, the command is taken to be authorized.

Table 10-14: Command list example 4

Command list	Input by user	Judgment
Authorized command list = "show" Unauthorized command list = "show ,ping"	show system	Allow
	ping 10.10.10.10	Deny

(Example 5)

If you do not set any command lists, all entered commands except logout and some others are denied.

Table 10-15: Command list example 5

Command list	Input by user	Judgment
Authorized command list: None set Unauthorized command list: None set	All commands	Deny
	logout, exit, quit, disable, end, set terminal, show whoami, who am i	Allow

(Example 6)

The root command class allows all commands to be executed with no authorization required. If you specify root, the authorized/unauthorized command class settings are invalidated, and the user can execute all commands including undocumented debugging commands (such as the ps command).

Table 10-16: Command list example 6

Command list	Input by user	Judgment
Command class = "root"	All commands (including undocumented debugging commands)	Allow

(Example 7)

If you set only an unauthorized command list, the user is authorized to execute all operation commands that do not match those in the list.

Table 10-17: Command list example 7

Command list	Input by user	Judgment
Authorized command list: None set Unauthorized command list = "reload"	All operation commands except reload	Allow
	reload	Deny

To illustrate how command authorization is implemented, assume that the following command restriction policies have been decided:

(5) Configuring RADIUS/TACACS +/Local Command Authorization

Based on the command restriction policy determined in Table 10-18: Command restriction policy example, in addition to the normal login authentication settings, configure RADIUS or TACACS + remote authentication server settings for command restriction using the following attribute values.

Note that if command authorization has not been configured on the server side, after authentication and successful login from a remote operation terminal you will not be authorized to execute any commands except logout, exit, quit, disable, end, set terminal, show whoami, and who am i. In this case, log in from the console.

Note, however, that if the console is also subject to command authorization by the configuration command aaa authorization commands console, the command is also restricted in the console.

• When using RADIUS servers

To implement command authorization with a RADIUS server, set up the server so that the following attributes will be returned at authentication.

Set these vendor-specific attributes in a dictionary file or other configuration file to register them with the RADIUS server.

VENDOR         ALAXALA                      21839
ATTRIBUTE      ALAXALA-Allow-Commands       101      string  ALAXALA
ATTRIBUTE      ALAXALA-Deny-Commands        102      string  ALAXALA

If you set the policy determined in Table 10-18: Command restriction policy example for a typical RADIUS server, you can use the following configuration example.

staff  Password = "******"
       Class = "allcommand"                                 .. 1
 
 
guest  Password = "******"
       Alaxala-Deny-Commands = "enable,reload,inactivate"   .. 2
 
 
test  Password = "******"
      Alaxala-Allow-Commands = "show ip "                   .. 3

Note: The asterisks (******) represent the user password.

1. The allcommand class permits all operation commands.

2. Prohibits commands beginning with enable, reload, or inactivate.

   Because allow-commands is not specified, all other commands are permitted.

3. Spaces are meaningful.

   Because show ip is followed by a space, commands such as show ip arp are permitted, but commands such as show ipv6 neighbors are not.

   All other commands are prohibited.

Notes

• When multiple Class entries are received on the Switch, the first entry is recognized and subsequent entries are ignored.

  Figure 10-19: Example of setting multiple Class entries

  Class = "noenable" .. 1 Class = "allcommand"

  1. Only the first noenable is valid.

• When multiple class names are registered in the Class entry on the Switch, the first class name is recognized and subsequent class names are ignored. For example, if you enter class="nomanage,noenable", only nomanage will be valid.

• When multiple entries are received with the ALAXALA-Deny-Commands attribute or ALAXALA-Allow-Commands attribute, a maximum of 1024 characters are recognized, including commas (,) and spaces. Subsequent characters are ignored. Also, if you specify multiple entries for the same attribute as in the example below, a comma (,) will be automatically placed in front of each entry on receipt of the second and subsequent entries.

  Figure 10-20: Example of setting multiple Deny-Commands entries

  ALAXALA-Deny-Commands = "inactivate,reload" .. 1 ALAXALA-Deny-Commands = "activate,test,............" .. 1

  1. The Switch can recognize the underlined parts up to a total of 1024 characters.

  As shown in the figure below, when the above Deny-Commands entries are received, a comma (,) is automatically placed in front of the activate command which is the first command in the second entry.

  Deny-Commands = "inactivate,reload,activate,test,........."

• When using TACACS+ servers

If you want to use a TACACS + server to restrict commands, set the following attribute-value pairs as authorization settings on TACACS + server:

When the policy determined in Table 10-18: Command restriction policy example is set for a typical TACACS + server, the following configuration file image is used.

user=staff {
    login = cleartext "******"
    service = taclogin {                                    .. 1
        class = "allcommand"
    }
}
 
 
user=guest {
    login = cleartext "******"
    service = taclogin {
        deny-commands = "enable,reload,inactivate"          .. 2
    }
}
 
 
user=test {
    login = cleartext "******"
    service = taclogin {
        allow-commands = "show ip "                         .. 3
    }
}

Note: The asterisks (******) represent the user password.

1. Sets taclogin as the service name.

   The allcommand class permits all operation commands.

2. Prohibits commands beginning with enable, reload, or inactivate.

   Because allow-commands is not specified, all other commands are permitted.

3. Spaces are meaningful.

   Because show ip is followed by a space, commands such as show ip arp are permitted, but commands such as show ipv6 neighbors are not.

   All other commands are prohibited.

Notes

• When multiple class names are registered in the Class entry of the Switch, the first class name is recognized and subsequent class names are ignored. For example, if you enter class="nomanage,noenable", only nomanage will be valid.

• For each of the deny-commands and allow-commands attributes, a maximum of 1024 characters are recognized, including commas (,) and spaces. Subsequent characters are ignored.

• When using local command authorization

When the policy determined in Table 10-18: Command restriction policy examples is set using local command authorization, the following configuration settings are used:

username guest view guest_view
username staff view-class allcommand                        .. 1
username test view test_view
!
parser view guest_view
  commands exec exclude all "enable"                        .. 2
  commands exec exclude all "inactivate"                    .. 2
  commands exec exclude all "reload"                        .. 2
!
parser view test_view
  commands exec include all "show ip "                      .. 3
!
aaa authentication login default local
aaa authorization commands default local

1. Assigns the allcommand class to the user staff, permitting all operation commands.

2. Prohibits commands beginning with enable, inactivate, or reload.

   Because commands exec include is not specified, all other commands are permitted.

3. Spaces are meaningful.

   Because show ip is followed by a space, commands such as show ip arp are permitted, but commands such as show ipv6 neighbors are not.

   All other commands are prohibited.

> show whoami
Date 20XX/01/07 12:00:00 UTC
staff ttyp0    -----  2   Jan  6 14:17 (10.10.10.10)
 
Home-directory: /usr/home/staff
Authentication: TACACS+ (Server 192.168.10.1)
Class: allcommand
      Allow: "all"
      Deny : -----
Command-list: -----
>
> show clock
Wed Jan 7 12:00:10 UTC 20XX
> /bin/date
% Command not authorized.
>

>show whoami
Date 20XX/01/07 12:00:00 UTC
guest ttyp0    -----  2   Jan  6 14:17 (10.10.10.20)
 
Home-directory: /usr/home/guest
Authentication: RADIUS (Server 192.168.10.1)
Class: -----
Command-list:
      Allow: -----
      Deny : "enable,reload,inactivate"
>
> show clock
Wed Jan 7 12:00:10 UTC 20XX
> reload
% Command not authorized.
>

>show whoami
Date 20XX/01/07 12:00:00 UTC
test ttyp0    -----  2   Jan  6 14:17 (10.10.10.30)
 
Home-directory: /usr/home/test
Authentication: LOCAL
Class: -----
Command-list:
      Allow: "show ip "
      Deny : -----
>
> show ip arp
***Command is executed***
> show ipv6 neighbors
% Command not authorized.
>