Switch Module Authentication

This chapter describes how to configure switch-based authentication on the CGR 2010 ESM, and contains the following topics:

Preventing Unauthorized Access to Your Switch Module

You can prevent unauthorized users from reconfiguring your switch module and viewing configuration information. Typically, you want network administrators to have access to your switch module while you restrict access to users who dial from outside the network through an asynchronous port, connect from outside the network through a serial port, or connect through a terminal or workstation from within the local network.

To prevent unauthorized access into your switch module, you should configure one or more of these security features:

  • At a minimum, you should configure passwords and privileges at each switch module port. These passwords are locally stored on the switch module. When users attempt to access the switch module through a port or line, they must enter the password specified for the port or line before they can access the switch module. For more information, see the “Protecting Access to Privileged EXEC Commands” section.
  • For an additional layer of security, you can also configure username and password pairs, which are locally stored on the switch module. These pairs are assigned to lines or ports and authenticate each user before that user can access the switch module. If you have defined privilege levels, you can also assign a specific privilege level (with associated rights and privileges) to each username and password pair. For more information, see the “Configuring Username and Password Pairs” section.
  • If you want to use username and password pairs, but you want to store them centrally on a server instead of locally, you can store them in a database on a security server. Multiple networking devices can then use the same database to obtain user authentication (and, if necessary, authorization) information. For more information, see the “Controlling Switch Module Access with TACACS+” section.

Protecting Access to Privileged EXEC Commands

A simple way of providing terminal access control in your network is to use passwords and assign privilege levels. Password protection restricts access to a network or network device. Privilege levels define what commands users can enter after they have logged into a network device.

Note For complete syntax and usage information for the commands used in this section, see the Cisco IOS Security Command Reference, Release 12.2.

Default Password and Privilege Level Configuration

Table 7-1 shows the default password and privilege level configuration.

 

Table 7-1 Default Password and Privilege Levels
Feature
Default Setting

Enable password and privilege level

No password is defined. The default is level 15 (privileged EXEC level). The password is not encrypted in the configuration file.

Enable secret password and privilege level

No password is defined. The default is level 15 (privileged EXEC level). The password is encrypted before it is written to the configuration file.

Line password

No password is defined

 

Setting or Changing a Static Enable Password

The enable password controls access to the privileged EXEC mode. Beginning in privileged EXEC mode, follow these steps to set or change a static enable password:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Define a new password or change an existing password for access to privileged EXEC mode.

By default, no password is defined.

For password, specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. It can contain the question mark (?) character if you precede the question mark with the key combination Crtl-v when you create the password; for example, to create the password abc?123, do this:

Enter abc.

Enter Crtl-v.

Enter ?123.

When the system prompts you to enter the enable password, you need not precede the question mark with the Ctrl-v; you can simply enter abc?123 at the password prompt.

enable password password

Step 3

Return to privileged EXEC mode.

end

Step 4

Verify your entries.

show running-config

Step 5

(Optional) Save your entries in the configuration file.

The enable password is not encrypted and can be read in the switch module configuration file.

copy running-config startup-config

 

To remove the password, use the no enable password global configuration command.

This example shows how to change the enable password to l1u2c3k4y5. The password is not encrypted and provides access to level 15 (traditional privileged EXEC mode access):

 

Switch(config)# enable password l1u2c3k4y5

 

Protecting Enable and Enable Secret Passwords with Encryption

To provide an additional layer of security, particularly for passwords that cross the network or that are stored on a Trivial File Transfer Protocol (TFTP) server, you can use either the enable password or enable secret global configuration commands. Both commands accomplish the same thing; that is, you can establish an encrypted password that users must enter to access privileged EXEC mode (the default) or any privilege level you specify.

We recommend that you use the enable secret command because it uses an improved encryption algorithm.

If you configure the enable secret command, it takes precedence over the enable password command; the two commands cannot be in effect simultaneously.

Beginning in privileged EXEC mode, follow these steps to configure encryption for enable and enable secret passwords:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Define a new password or change an existing password for access to privileged EXEC mode.

or

Define a secret password, which is saved using a nonreversible encryption method.

  • (Optional) For level, the range is from 0 to 15. Level 1 is normal user EXEC mode privileges. The default level is 15 (privileged EXEC mode privileges).
  • For password, specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined.
  • (Optional) For encryption-type, only type 5, a Cisco proprietary encryption algorithm, is available. If you specify an encryption type, you must provide an encrypted password—an encrypted password that you copy from another switch module configuration.

Note If you specify an encryption type and then enter a clear text password, you can not re-enter privileged EXEC mode. You cannot recover a lost encrypted password by any method.

enable password [ level level ] { password | encryption-type encrypted- password }

or

enable secret [ level level ] { password | encryption-type encrypted- password }

Step 3

(Optional) Encrypt the password when the password is defined or when the configuration is written.

Encryption prevents the password from being readable in the configuration file.

service password-encryption

Step 4

Return to privileged EXEC mode.

end

Step 5

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

If both the enable and enable secret passwords are defined, users must enter the enable secret password.

Use the level keyword to define a password for a specific privilege level. After you specify the level and set a password, give the password only to users who need to have access at this level. Use the privilege level global configuration command to specify commands accessible at various levels. For more information, see the “Configuring Multiple Privilege Levels” section.

If you enable password encryption, it applies to all passwords including username passwords, authentication key passwords, the privileged command password, and console and virtual terminal line passwords.

To remove a password and level, use the no enable password [ level level ] or no enable secret [ level level ] global configuration command. To disable password encryption, use the no service password-encryption global configuration command.

This example shows how to configure the encrypted password $1$FaD0$Xyti5Rkls3LoyxzS8 for privilege level 2:

 

Switch(config)# enable secret level 2 5 $1$FaD0$Xyti5Rkls3LoyxzS8

 

Disabling Password Recovery

By default, any end user with physical access to the switch module can recover from a lost password by interrupting the boot process while the switch module is powering on and then by entering a new password.

The password-recovery disable feature protects access to the switch module password by disabling part of this functionality. When this feature is enabled, the end user can interrupt the boot process only by agreeing to set the system back to the default configuration. With password recovery disabled, you can still interrupt the boot process and change the password, but the configuration file (config.text) and the VLAN database file (vlan.dat) are deleted.

Note If you disable password recovery, we recommend that you keep a backup copy of the configuration file on a secure server in case the end user interrupts the boot process and sets the system back to default values. Do not keep a backup copy of the configuration file on the switch module. We recommend that you also keep a backup copy of the VLAN database file on a secure server. When the switch module is returned to the default system configuration, you can download the saved files to the switch module by using the XMODEM protocol. For more information, see the “Recovering from a Lost or Forgotten Password” section.

Beginning in privileged EXEC mode, follow these steps to disable password recovery:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Disable password recovery.

This setting is saved in an area of the flash memory that is accessible by the boot loader and the Cisco IOS image, but it is not part of the file system and is not accessible by any user.

no service password-recovery

Step 3

Return to privileged EXEC mode.

end

Step 4

Verify the configuration by checking the last few lines of the command output.

show version

To re-enable password recovery, use the service password-recovery global configuration command.

Note Disabling password recovery will not work if you have set the switch module to boot manually by using the boot manual global configuration command. This command produces the boot loader prompt (switch:) after the switch module is power cycled.

Setting a Telnet Password for a Terminal Line

When you power-up your switch module for the first time, an automatic setup program runs to assign IP information and to create a default configuration for continued use. The setup program also prompts you to configure your switch module for Telnet access through a password. If you did not configure this password during the setup program, you can configure it now through the command-line interface (CLI).

Beginning in privileged EXEC mode, follow these steps to configure your switch module for Telnet access:

 

Step
Command

Step 1

Attach a PC or workstation with emulation software to the Cisco CGR 2010 router console port.

The default data characteristics of the console port are 9600, 8, 1, no parity. You might need to press the Return key several times to see the command-line prompt.

 

Step 2

Enter privileged EXEC mode.

enable password password

Step 3

Enter global configuration mode.

configure terminal

Step 4

Configure the number of Telnet sessions (lines), and enter line configuration mode.

There are 16 possible sessions on a command-capable switch module. The 0 and 15 mean that you are configuring all 16 possible Telnet sessions.

line vty 0 15

Step 5

Enter a Telnet password for the line or lines.

For password, specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined.

password password

Step 6

Return to privileged EXEC mode.

end

Step 7

Verify your entries.

The password is listed under the command line vty 0 15.

show running-config

Step 8

(Optional) Save your entries in the configuration file.

copy running-config startup-config

To remove the password, use the no password global configuration command.

This example shows how to set the Telnet password to let45me67in89 :

 

Switch(config)# line vty 10
Switch(config-line)# password let45me67in89

 

Configuring Username and Password Pairs

You can configure username and password pairs, which are locally stored on the switch module. These pairs are assigned to lines or ports and authenticate each user before that user can access the switch module. If you have defined privilege levels, you can also assign a specific privilege level (with associated rights and privileges) to each username and password pair.

Beginning in privileged EXEC mode, follow these steps to establish a username-based authentication system that requests a login username and a password:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enter the username, privilege level, and password for each user.

  • For name, specify the user ID as one word. Spaces and quotation marks are not allowed.
  • (Optional) For level, specify the privilege level the user has after gaining access. The range is 0 to 15. Level 15 gives privileged EXEC mode access. Level 1 gives user EXEC mode access.
  • For encryption-type, enter 0 to specify that an unencrypted password will follow. Enter 7 to specify that a hidden password will follow.
  • For password, specify the password the user must enter to gain access to the switch module. The password must be from 1 to 25 characters, can contain embedded spaces, and must be the last option specified in the username command.

username name [ privilege level ] { password encryption-type password }

Step 3

Enter line configuration mode, and configure the console port (line 0) or the VTY lines (line 0 to 15).

line console 0

or

line vty 0 15

Step 4

Enable local password checking at login time. Authentication is based on the username specified in Step 2.

login local

Step 5

Return to privileged EXEC mode.

end

Step 6

Verify your entries.

show running-config

Step 7

(Optional) Save your entries in the configuration file.

copy running-config startup-config

To disable username authentication for a specific user, use the no username name global configuration command. To disable password checking and allow connections without a password, use the no login line configuration command.

Configuring Multiple Privilege Levels

By default, the Cisco IOS software has two modes of password security: user EXEC and privileged EXEC. You can configure up to 16 hierarchical levels of commands for each mode. By configuring multiple passwords, you can allow different sets of users to have access to specified commands.

For example, if you want many users to have access to the clear line command, you can assign it level 2 security and distribute the level 2 password fairly widely. But if you want more restricted access to the configure command, you can assign it level 3 security and distribute that password to a more restricted group of users.

These sections contain this configuration information:

Setting the Privilege Level for a Command

Beginning in privileged EXEC mode, follow these steps to set the privilege level for a command mode:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Set the privilege level for a command.

  • For mode, enter configure for global configuration mode, exec for EXEC mode, interface for interface configuration mode, or line for line configuration mode.
  • For level, the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges. Level 15 is the level of access permitted by the enable password.
  • For command, specify the command to which you want to restrict access.

privilege mode level level command

Step 3

Specify the enable password for the privilege level.

  • For level, the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges.
  • For password, specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. By default, no password is defined.

enable password level level password

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

The first command shows the password and access level configuration. The second command shows the privilege level configuration.

show running-config

or

show privilege

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

When you set a command to a privilege level, all commands whose syntax is a subset of that command are also set to that level. For example, if you set the show ip traffic command to level 15, the show commands and show ip commands are automatically set to privilege level 15 unless you set them individually to different levels.

To return to the default privilege for a given command, use the no privilege mode level level command global configuration command.

This example shows how to set the configure command to privilege level 14 and define SecretPswd14 as the password users must enter to use level 14 commands:

 

Switch(config)# privilege exec level 14 configure
Switch(config)# enable password level 14 SecretPswd14

 

Changing the Default Privilege Level for Lines

Beginning in privileged EXEC mode, follow these steps to change the default privilege level for a line:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Select the virtual terminal line on which to restrict access.

line vty line

Step 3

Change the default privilege level for the line.

For level, the range is from 0 to 15. Level 1 is for normal user EXEC mode privileges. Level 15 is the level of access permitted by the enable password.

privilege level level

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

The first command shows the password and access level configuration. The second command shows the privilege level configuration.

show running-config

or

show privilege

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

Users can override the privilege level you set using the privilege level line configuration command by logging in to the line and enabling a different privilege level. They can lower the privilege level by using the disable command. If users know the password to a higher privilege level, they can use that password to enable the higher privilege level. You might specify a high level or privilege level for your console line to restrict line usage.

To return to the default line privilege level, use the no privilege level line configuration command.

Logging into and Exiting a Privilege Level

Beginning in privileged EXEC mode, follow these steps to log in to a specified privilege level and to exit to a specified privilege level:

 

Step
Command

Step 1

Log in to a specified privilege level. For level, the range is 0 to 15.

enable level

Step 2

Exit to a specified privilege level. For level, the range is 0 to 15.

disable level

Controlling Switch Module Access with TACACS+

This section describes how to enable and configure Terminal Access Controller Access Control System Plus (TACACS+), which provides detailed accounting information and flexible administrative control over authentication and authorization processes. TACACS+ is facilitated through authentication, authorization, accounting (AAA) and can be enabled only through AAA commands.

Note For complete syntax and usage information for the commands used in this section, see the Cisco IOS Security Command Reference, Release 12.2.

These sections contain this configuration information:

Understanding TACACS+

TACACS+ is a security application that provides centralized validation of users attempting to gain access to your switch module. TACACS+ services are maintained in a database on a TACACS+ daemon typically running on a UNIX or Windows NT workstation. You should have access to and should configure a TACACS+ server before the configuring TACACS+ features on your switch module.

TACACS+ provides for separate and modular authentication, authorization, and accounting facilities. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide each service—authentication, authorization, and accounting—independently. Each service can be tied into its own database to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon.

The goal of TACACS+ is to provide a method for managing multiple network access points from a single management service. Your switch module can be a network access server along with other Cisco routers and access servers. A network access server provides connections to a single user, to a network or subnetwork, and to interconnected networks as shown in Figure 7-1.

Figure 7-1 Typical TACACS+ Network Configuration

 

 

TACACS+, administered through the AAA security services, can provide these services:

  • Authentication—Provides complete control of authentication through login and password dialog, challenge and response, and messaging support.

The authentication facility can conduct a dialog with the user (for example, after a username and password are provided, to challenge a user with several questions, such as home address, mother’s maiden name, service type, and social security number). The TACACS+ authentication service can also send messages to user screens. For example, a message could notify users that their passwords must be changed because of the company’s password aging policy.

  • Authorization—Provides fine-grained control over user capabilities for the duration of the user’s session, including but not limited to setting autocommands, access control, session duration, or protocol support. You can also enforce restrictions on what commands a user can execute with the TACACS+ authorization feature.
  • Accounting—Collects and sends information used for billing, auditing, and reporting to the TACACS+ daemon. Network managers can use the accounting facility to track user activity for a security audit or to provide information for user billing. Accounting records include user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes.

The TACACS+ protocol provides authentication between the switch module and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between the switch module and the TACACS+ daemon are encrypted.

You need a system running the TACACS+ daemon software to use TACACS+ on your switch module.

TACACS+ Operation

When a user attempts a simple ASCII login by authenticating to a switch module using TACACS+, the following process occurs:

1. When the connection is established, the switch module contacts the TACACS+ daemon to obtain a username prompt to show to the user. The user enters a username, and the switch module then contacts the TACACS+ daemon to obtain a password prompt. the switch module displays the password prompt to the user, the user enters a password, and the password is then sent to the TACACS+ daemon.

TACACS+ allows a dialog between the daemon and the user until the daemon receives enough information to authenticate the user. The daemon prompts for a username and password combination, but can include other items, such as the user’s mother’s maiden name.

2. The switch module eventually receives one of these responses from the TACACS+ daemon:

  • ACCEPT—The user is authenticated and service can begin. If the switch module is configured to require authorization, authorization begins at this time.
  • REJECT—The user is not authenticated. The user can be denied access or is prompted to retry the login sequence, depending on the TACACS+ daemon.
  • ERROR—An error occurred at some time during authentication with the daemon or in the network connection between the daemon and the switch module. If an ERROR response is received, the switch module typically tries to use an alternative method for authenticating the user.
  • CONTINUE—The user is prompted for additional authentication information.

After authentication, the user undergoes an additional authorization phase if authorization has been enabled on the switch module. Users must first successfully complete TACACS+ authentication before proceeding to TACACS+ authorization.

3. If TACACS+ authorization is required, the TACACS+ daemon is again contacted, and it returns an ACCEPT or REJECT authorization response. If an ACCEPT response is returned, the response contains data in the form of attributes that direct the EXEC or NETWORK session for that user and the services that the user can access:

  • Telnet, Secure Shell (SSH), rlogin, or privileged EXEC services
  • Connection parameters, including the host or client IP address, access list, and user timeouts

Configuring TACACS+

This section describes how to configure your switch module to support TACACS+. At a minimum, you must identify the host or hosts maintaining the TACACS+ daemon and define the method lists for TACACS+ authentication. You can optionally define method lists for TACACS+ authorization and accounting. A method list defines the sequence and methods to be used to authenticate, to authorize, or to keep accounts on a user. You can use method lists to designate one or more security protocols to be used, ensuring a backup system if the initial method fails. The software uses the first method listed to authenticate, to authorize, or to keep accounts on users; if that method does not respond, the software selects the next method in the list. This process continues until there is successful communication with a listed method or the method list is exhausted.

The aaa authorization console global configuration command that allows you to enable AAA and TACACS+ to work on the console port.

For information about the command, see this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/srfauth.html

These sections contain this configuration information:

Default TACACS+ Configuration

TACACS+ and AAA are disabled by default.

To prevent a lapse in security, you cannot configure TACACS+ through a network management application. When enabled, TACACS+ can authenticate users accessing the switch module through the CLI.

Note Although TACACS+ configuration is performed through the CLI, the TACACS+ server authenticates HTTP connections that have been configured with a privilege level of 15.

Identifying the TACACS+ Server Host and Setting the Authentication Key

You can configure the switch module to use a single server or AAA server groups to group existing server hosts for authentication. You can group servers to select a subset of the configured server hosts and use them for a particular service. The server group is used with a global server-host list and contains the list of IP addresses of the selected server hosts.

Beginning in privileged EXEC mode, follow these steps to identify the IP host or host maintaining TACACS+ server and optionally set the encryption key:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Identify the IP host or hosts maintaining a TACACS+ server. Enter this command multiple times to create a list of preferred hosts. The software searches for hosts in the order in which you specify them.

  • For hostname, specify the name or IP address of the host.
  • (Optional) For port integer, specify a server port number. The default is port 49. The range is 1 to 65535.
  • (Optional) For timeout integer, specify a time in seconds the switch module waits for a response from the daemon before it times out and declares an error. The default is 5 seconds. The range is 1 to 1000 seconds.
  • (Optional) For key string, specify the encryption key for encrypting and decrypting all traffic between the switch module and the TACACS+ daemon. You must configure the same key on the TACACS+ daemon for encryption to be successful.

tacacs-server host hostname [ port integer ] [ timeout integer ] [ key string ]

Step 3

Enable AAA.

aaa new-model

Step 4

(Optional) Define the AAA server-group with a group name.

This command puts the switch module in a server group subconfiguration mode.

aaa group server tacacs+ group-name

Step 5

(Optional) Associate a particular TACACS+ server with the defined server group. Repeat this step for each TACACS+ server in the AAA server group.

Each server in the group must be previously defined in Step 2.

server ip-address

Step 6

Return to privileged EXEC mode.

end

Step 7

Verify your entries.

show tacacs

Step 8

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To remove the specified TACACS+ server name or address, use the no tacacs-server host hostname global configuration command. To remove a server group from the configuration list, use the no aaa group server tacacs+ group-name global configuration command. To remove the IP address of a TACACS+ server, use the no server ip-address server group subconfiguration command.

Configuring TACACS+ Login Authentication

To configure AAA authentication, you define a named list of authentication methods and then apply that list to various ports. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific port before any of the defined authentication methods are performed. The only exception is the default method list (which, by coincidence, is named default). The default method list is automatically applied to all ports except those that have a named method list explicitly defined. A defined method list overrides the default method list.

A method list describes the sequence and authentication methods to be queried to authenticate a user. You can designate one or more security protocols to be used for authentication, ensuring a backup system for authentication in case the initial method fails. The software uses the first method listed to authenticate users; if that method fails to respond, the software selects the next authentication method in the method list. This process continues until there is successful communication with a listed authentication method or until all defined methods are exhausted. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.

Beginning in privileged EXEC mode, follow these steps to configure login authentication:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable AAA.

aaa new-model

 

To disable AAA, use the no aaa new-model global configuration command. To disable AAA authentication, use the no aaa authentication login {default | list-name } method1 [ method2... ] global configuration command. To either disable TACACS+ authentication for logins or to return to the default value, use the no login authentication { default | list-name } line configuration command.

Configuring TACACS+ Authorization for Privileged EXEC Access and Network Services

AAA authorization limits the services available to a user. When AAA authorization is enabled, the switch module uses information retrieved from the user’s profile, which is located either in the local user database or on the security server, to configure the user’s session. The user is granted access to a requested service only if the information in the user profile allows it.

You can use the aaa authorization global configuration command with the tacacs+ keyword to set parameters that restrict a user’s network access to privileged EXEC mode.

The aaa authorization exec tacacs+ local command sets these authorization parameters:

  • Use TACACS+ for privileged EXEC access authorization if authentication was performed by using TACACS+
  • Use the local database if authentication was not performed by using TACACS+

Note Authorization is bypassed for authenticated users who log in through the CLI even if authorization has been configured.

Beginning in privileged EXEC mode, follow these steps to specify TACACS+ authorization for privileged EXEC access and network services:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Configure the switch module for user TACACS+ authorization for all network-related service requests.

aaa authorization network tacacs+

Step 3

Configure the switch module for user TACACS+ authorization if the user has privileged EXEC access.

The exec keyword might return user profile information (such as autocommand information).

aaa authorization exec tacacs+

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

show running-config

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To disable authorization, use the no aaa authorization { network | exec } method1 global configuration command.

Starting TACACS+ Accounting

The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are consuming. When AAA accounting is enabled, the switch module reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then be analyzed for network management, client billing, or auditing.

Beginning in privileged EXEC mode, follow these steps to enable TACACS+ accounting for each Cisco IOS privilege level and for network services:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable TACACS+ accounting for all network-related service requests.

aaa accounting network start-stop tacacs+

Step 3

Enable TACACS+ accounting to send a start-record accounting notice at the beginning of a privileged EXEC process and a stop-record at the end.

aaa accounting exec start-stop tacacs+

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

show running-config

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To disable accounting, use the no aaa accounting { network | exec } { start-stop } method1... global configuration command.

Displaying the TACACS+ Configuration

To display TACACS+ server statistics, use the show tacacs privileged EXEC command.

Controlling Switch Module Access with RADIUS

This section describes how to enable and configure the RADIUS, which provides detailed accounting information and flexible administrative control over authentication and authorization processes. RADIUS is facilitated through AAA and can be enabled only through AAA commands.

Note For complete syntax and usage information for the commands used in this section, see the Cisco IOS Security Command Reference, Release 12.2.

These sections contain the following configuration information:

Understanding RADIUS

RADIUS is a distributed client/server system that secures networks against unauthorized access. RADIUS clients run on supported Cisco routers and switches. Clients send authentication requests to a central RADIUS server, which contains all user authentication and network service access information.

The RADIUS host is normally a multiuser system running RADIUS server software from Cisco (Cisco Secure Access Control Server Version 3.0), Livingston, Merit, Microsoft, or another software provider. For more information, see the RADIUS server documentation.

Use RADIUS in these network environments that require access security:

  • Networks with multiple-vendor access servers, each supporting RADIUS. For example, access servers from several vendors use a single RADIUS server-based security database. In an IP-based network with multiple vendors’ access servers, dial-in users are authenticated through a RADIUS server that has been customized to work with the Kerberos security system.
  • Turnkey network security environments in which applications support the RADIUS protocol, such as in an access environment that uses a smart card access control system. In one case, RADIUS has been used with Enigma’s security cards to validates users and to grant access to network resources.
  • Networks already using RADIUS. You can add a Cisco switch containing a RADIUS client to the network. This might be the first step when you make a transition to a TACACS+ server. See Figure 7-2.
  • Network in which the user must only access a single service. Using RADIUS, you can control user access to a single host, to a single utility such as Telnet, or to the network through a protocol such as IEEE 802.1x. For more information about this protocol, see Chapter 10, “Configuring IEEE 802.1x Port-Based Authentication,” in the Cisco CGS 2520 Software Configuration Guide.
  • Networks that require resource accounting. You can use RADIUS accounting independently of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, showing the amount of resources (such as time, packets, bytes, and so forth) used during the session. An Internet service provider might use a freeware-based version of RADIUS access control and accounting software to meet special security and billing needs.

RADIUS is not suitable in these network security situations:

  • Multiprotocol access environments. RADIUS does not support AppleTalk Remote Access (ARA), NetBIOS Frame Control Protocol (NBFCP), NetWare Asynchronous Services Interface (NASI), or X.25 PAD connections.
  • Switch-to-switch or router-to-router situations. RADIUS does not provide two-way authentication. RADIUS can be used to authenticate from one device to a non-Cisco device if the non-Cisco device requires authentication.
  • Networks using a variety of services. RADIUS generally binds a user to one service model.

Figure 7-2 Transitioning from RADIUS to TACACS+ Services

 

RADIUS Operation

When a user attempts to log in and authenticate to a switch module that is access-controlled by a RADIUS server:

1. The user is prompted to enter a username and password.

2. The username and encrypted password are sent over the network to the RADIUS server.

3. The user receives one of these responses from the RADIUS server:

a. ACCEPT—The user is authenticated.

b. REJECT—The user is either not authenticated and is prompted to re-enter the username and password, or access is denied.

c. CHALLENGE—A challenge requires additional data from the user.

d. CHALLENGE PASSWORD—A response requests the user to select a new password.

The ACCEPT or REJECT response is bundled with additional data that is used for privileged EXEC or network authorization. Users must first successfully complete RADIUS authentication before proceeding to RADIUS authorization, if it is enabled. The additional data included with the ACCEPT or REJECT packets includes these items:

  • Telnet, SSH, rlogin, or privileged EXEC services
  • Connection parameters, including the host or client IP address, access list, and user timeouts.

Configuring RADIUS

This section describes how to configure your switch module to support RADIUS. At a minimum, you must identify the host or hosts that run the RADIUS server software and define the method lists for RADIUS authentication. You can optionally define method lists for RADIUS authorization and accounting.

A method list defines the sequence and methods to be used to authenticate, to authorize, or to keep accounts on a user. You can use method lists to designate one or more security protocols to be used (such as TACACS+ or local username lookup), ensuring a backup system if the initial method fails. The software uses the first method listed to authenticate, to authorize, or to keep accounts on users; if that method does not respond, the software selects the next method in the list. This process continues until there is successful communication with a listed method or the method list is exhausted.

You should have access to and should configure a RADIUS server before configuring RADIUS features on your switch module.

These sections contain this configuration information:

Default RADIUS Configuration

RADIUS and AAA are disabled by default.

To prevent a lapse in security, you cannot configure RADIUS through a network management application. When enabled, RADIUS can authenticate users accessing the switch module through the CLI.

Identifying the RADIUS Server Host

Switch-to-RADIUS-server communication involves several components:

  • Hostname or IP address
  • Authentication destination port
  • Accounting destination port
  • Key string
  • Timeout period
  • Retransmission value

You identify RADIUS security servers by their hostname or IP address, hostname and specific UDP port numbers, or their IP address and specific UDP port numbers. The combination of the IP address and the UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address.

If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry configured acts as a fail-over backup to the first one. Using this example, if the first host entry fails to provide accounting services, the switch module tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order that they are configured.)

A RADIUS server and the switch module use a shared secret text string to encrypt passwords and exchange responses. To configure RADIUS to use the AAA security commands, you must specify the host running the RADIUS server daemon and a secret text (key) string that it shares with the switch module.

The timeout, retransmission, and encryption key values can be configured globally for all RADIUS servers, on a per-server basis, or in some combination of global and per-server settings. To apply these settings globally to all RADIUS servers communicating with the switch module, use the three unique global configuration commands: radius-server timeout, radius-server retransmit, and radius-server key. To apply these values on a specific RADIUS server, use the radius-server host global configuration command.

You can configure the switch module to use AAA server groups to group existing server hosts for authentication. For more information, see the “Defining AAA Server Groups” section.

Beginning in privileged EXEC mode, follow these steps to configure per-server RADIUS server communication. This procedure is required.

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable AAA authentication.

aaa new-model

Step 3

Specify the IP address or hostname of the remote RADIUS server host.

  • (Optional) For auth-port port-number, specify the UDP destination port for authentication requests.
  • (Optional) For acct-port port-number, specify the UDP destination port for accounting requests.
  • (Optional) For timeout seconds, specify the time interval that the switch module waits for the RADIUS server to reply before resending. The range is 1 to 1000. This setting overrides the radius-server timeout global configuration command setting. If no timeout is set with the radius-server host command, the setting of the radius-server timeout command is used.
  • (Optional) For retransmit retries, specify the number of times a RADIUS request is resent to a server if that server is not responding or responding slowly. The range is 1 to 1000. If no retransmit value is set with the radius-server host command, the setting of the radius-server retransmit global configuration command is used.
  • (Optional) For key string, specify the authentication and encryption key used between the switch module and the RADIUS daemon running on the RADIUS server.

Note The key is a text string that must match the encryption key used on the RADIUS server. Always configure the key as the last item in the radius-server host command. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

To configure the switch module to recognize more than one host entry associated with a single IP address, enter this command as many times as necessary, making sure that each UDP port number is different. the switch module software searches for hosts in the order in which you specify them. Set the timeout, retransmit, and encryption key values to use with the specific RADIUS host.

radius-server host { hostname | ip-address } [ auth-port port-number ] [ acct-port port-number ] [ timeout seconds ] [ retransmit retries ] [ key string ]

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

show running-config

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To remove the specified RADIUS server, use the no radius-server host hostname | ip-address global configuration command.

This example shows how to configure one RADIUS server to be used for authentication and another to be used for accounting:

 

Switch(config)# radius-server host 172.29.36.49 auth-port 1612 key rad1
Switch(config)# radius-server host 172.20.36.50 acct-port 1618 key rad2

 

This example shows how to configure host1 as the RADIUS server and to use the default ports for both authentication and accounting:

 

Switch(config)# radius-server host host1

 

Note You also need to configure some settings on the RADIUS server. These settings include the IP address of the switch module and the key string to be shared by both the server and the switch module. For more information, see the RADIUS server documentation.

Configuring RADIUS Login Authentication

To configure AAA authentication, you define a named list of authentication methods and then apply that list to various ports. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific port before any of the defined authentication methods are performed. The only exception is the default method list (which, by coincidence, is named default). The default method list is automatically applied to all ports except those that have a named method list explicitly defined.

A method list describes the sequence and authentication methods to be queried to authenticate a user. You can designate one or more security protocols to be used for authentication, ensuring a backup system for authentication in case the initial method fails. The software uses the first method listed to authenticate users; if that method fails to respond, the software selects the next authentication method in the method list. This process continues until there is successful communication with a listed authentication method or until all defined methods are exhausted. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.

Beginning in privileged EXEC mode, follow these steps to configure login authentication. This procedure is required.

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable AAA.

aaa new-model

Step 3

Create a login authentication method list.

  • To create a default list that is used when a named list is not specified in the login authentication command, use the default keyword followed by the methods that are to be used in default situations. The default method list is automatically applied to all ports.
  • For list-name, specify a character string to name the list you are creating.
  • For method1..., specify the actual method the authentication algorithm tries. The additional methods of authentication are used only if the previous method returns an error, not if it fails.

Select one of these methods:

– enable —Use the enable password for authentication. Before you can use this authentication method, you must define an enable password by using the enable password global configuration command.

– group radius —Use RADIUS authentication. Before you can use this authentication method, you must configure the RADIUS server. For more information, see the “Identifying the RADIUS Server Host” section.

– line —Use the line password for authentication. Before you can use this authentication method, you must define a line password. Use the password password line configuration command.

– local —Use the local username database for authentication. You must enter username information in the database. Use the username name password global configuration command.

– local-case —Use a case-sensitive local username database for authentication. You must enter username information in the database by using the username password global configuration command.

– none —Do not use any authentication for login.

aaa authentication login { default | list-name } method1 [ method2... ]

Step 4

Enter line configuration mode, and configure the lines to which you want to apply the authentication list.

line [ console | tty | vty ] line-number [ ending-line-number ]

Step 5

Apply the authentication list to a line or set of lines.

  • If you specify default, use the default list created with the aaa authentication login command.
  • For list-name, specify the list created with the aaa authentication login command.

login authentication { default | list-name }

Step 6

Return to privileged EXEC mode.

end

Step 7

Verify your entries.

show running-config

Step 8

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To disable AAA, use the no aaa new-model global configuration command. To disable AAA authentication, use the no aaa authentication login {default | list-name } method1 [ method2... ] global configuration command. To either disable RADIUS authentication for logins or to return to the default value, use the no login authentication { default | list-name } line configuration command.

Defining AAA Server Groups

You can configure the switch module to use AAA server groups to group existing server hosts for authentication. You select a subset of the configured server hosts and use them for a particular service. The server group is used with a global server-host list, which lists the IP addresses of the selected server hosts.

Server groups also can include multiple host entries for the same server if each entry has a unique identifier (the combination of the IP address and UDP port number), allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. If you configure two different host entries on the same RADIUS server for the same service, (for example, accounting), the second configured host entry acts as a fail-over backup to the first one.

You use the server group server configuration command to associate a particular server with a defined group server. You can either identify the server by its IP address or identify multiple host instances or entries by using the optional auth-port and acct-port keywords.

Beginning in privileged EXEC mode, follow these steps to define the AAA server group and associate a particular RADIUS server with it:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Specify the IP address or hostname of the remote RADIUS server host.

  • (Optional) For auth-port port-number, specify the UDP destination port for authentication requests.
  • (Optional) For acct-port port-number, specify the UDP destination port for accounting requests.
  • (Optional) For timeout seconds, specify the time interval that the switch module waits for the RADIUS server to reply before resending. The range is 1 to 1000. This setting overrides the radius-server timeout global configuration command setting. If no timeout is set with the radius-server host command, the setting of the radius-server timeout command is used.
  • (Optional) For retransmit retries, specify the number of times a RADIUS request is resent to a server if that server is not responding or responding slowly. The range is 1 to 1000. If no retransmit value is set with the radius-server host command, the setting of the radius-server retransmit global configuration command is used.
  • (Optional) For key string, specify the authentication and encryption key used between the switch module and the RADIUS daemon running on the RADIUS server.

Note The key is a text string that must match the encryption key used on the RADIUS server. Always configure the key as the last item in the radius-server host command. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

To configure the switch module to recognize more than one host entry associated with a single IP address, enter this command as many times as necessary, making sure that each UDP port number is different. The switch module software searches for hosts in the order in which you specify them. Set the timeout, retransmit, and encryption key values to use with the specific RADIUS host.

radius-server host { hostname | ip-address } [ auth-port port-number ] [ acct-port port-number ] [ timeout seconds ] [ retransmit retries ] [ key string ]

Step 3

Enable AAA.

aaa new-model

Step 4

Define the AAA server-group with a group name.

This command puts the switch module in a server group configuration mode.

aaa group server radius group-name

Step 5

Associate a particular RADIUS server with the defined server group. Repeat this step for each RADIUS server in the AAA server group.

Each server in the group must be previously defined in Step 2.

server ip-address

Step 6

Return to privileged EXEC mode.

end

Step 7

Verify your entries.

show running-config

Step 8

(Optional) Save your entries in the configuration file.

copy running-config startup-config

Step 9

Enable RADIUS login authentication. See the “Configuring RADIUS Login Authentication” section.

 

 

To remove the specified RADIUS server, use the no radius-server host hostname | ip-address global configuration command. To remove a server group from the configuration list, use the no aaa group server radius group-name global configuration command. To remove the IP address of a RADIUS server, use the no server ip-address server group configuration command.

In this example, the switch module is configured to recognize two different RADIUS group servers ( group1 and group2). Group1 has two different host entries on the same RADIUS server configured for the same services. The second host entry acts as a fail-over backup to the first entry.

 

Switch(config)# radius-server host 172.20.0.1 auth-port 1000 acct-port 1001
Switch(config)# radius-server host 172.10.0.1 auth-port 1645 acct-port 1646
Switch(config)# aaa new-model
Switch(config)# aaa group server radius group1
Switch(config-sg-radius)# server 172.20.0.1 auth-port 1000 acct-port 1001
Switch(config-sg-radius)# exit
Switch(config)# aaa group server radius group2
Switch(config-sg-radius)# server 172.20.0.1 auth-port 2000 acct-port 2001
Switch(config-sg-radius)# exit

 

Configuring RADIUS Authorization for User Privileged Access and Network Services

AAA authorization limits the services available to a user. When AAA authorization is enabled, the switch module uses information retrieved from the user’s profile, which is in the local user database or on the security server, to configure the user’s session. The user is granted access to a requested service only if the information in the user profile allows it.

You can use the aaa authorization global configuration command with the radius keyword to set parameters that restrict a user’s network access to privileged EXEC mode.

The aaa authorization exec radius local command sets these authorization parameters:

  • Use RADIUS for privileged EXEC access authorization if authentication was performed by using RADIUS
  • Use the local database if authentication was not performed by using RADIUS

Note Authorization is bypassed for authenticated users who log in through the CLI even if authorization has been configured.

Beginning in privileged EXEC mode, follow these steps to specify RADIUS authorization for privileged EXEC access and network services:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Configure the switch module for user RADIUS authorization for all network-related service requests.

aaa authorization network radius

Step 3

Configure the switch module for user RADIUS authorization if the user has privileged EXEC access.

The exec keyword might return user profile information (such as autocommand information).

aaa authorization exec radius

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

show running-config

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To disable authorization, use the no aaa authorization { network | exec } method1 global configuration command.

Starting RADIUS Accounting

The AAA accounting feature tracks the services that users are accessing and the amount of network resources that they are consuming. When AAA accounting is enabled, the switch module reports user activity to the RADIUS security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can then be analyzed for network management, client billing, or auditing.

Beginning in privileged EXEC mode, follow these steps to enable RADIUS accounting for each Cisco IOS privilege level and for network services:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable RADIUS accounting for all network-related service requests.

aaa accounting network start-stop radius

Step 3

Enable RADIUS accounting to send a start-record accounting notice at the beginning of a privileged EXEC process and a stop-record at the end.

aaa accounting exec start-stop radius

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your entries.

show running-config

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To disable accounting, use the no aaa accounting { network | exec } { start-stop } method1... global configuration command.

Configuring Settings for All RADIUS Servers

Beginning in privileged EXEC mode, follow these steps to configure global communication settings between the switch module and all RADIUS servers:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Specify the shared secret text string used between the switch module and all RADIUS servers.

Note The key is a text string that must match the encryption key used on the RADIUS server. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

radius-server key string

Step 3

Specify the number of times the switch module sends each RADIUS request to the server before giving up. The default is 3; the range 1 to 1000.

radius-server retransmit retries

Step 4

Specify the number of seconds a switch module waits for a reply to a RADIUS request before resending the request. The default is 5 seconds; the range is 1 to 1000.

radius-server timeout seconds

Step 5

Specify the number of minutes a RADIUS server, which is not responding to authentication requests, to be skipped, avoiding the wait for the request to timeout before trying the next configured server. The default is 0; the range is 1 to 1440 minutes.

radius-server deadtime minutes

Step 6

Return to privileged EXEC mode.

end

Step 7

Verify your settings.

show running-config

Step 8

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To return to the default setting for the retransmit, timeout, and deadtime, use the no forms of these commands.

Configuring the Switch Module to Use Vendor-Specific RADIUS Attributes

The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific information between the switch module and the RADIUS server by using the vendor-specific attribute (attribute 26). Vendor-specific attributes (VSAs) allow vendors to support their own extended attributes not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option by using the format recommended in the specification. Cisco’s vendor-ID is 9, and the supported option has vendor-type 1, which is named cisco-avpair. The value is a string with this format:

 

protocol : attribute sep value *

 

Protocol is a value of the Cisco protocol attribute for a particular type of authorization. Attribute and value are an appropriate attribute-value (AV) pair defined in the Cisco TACACS+ specification, and sep is = for mandatory attributes and is * for optional attributes. The full set of features available for TACACS+ authorization can then be used for RADIUS.

For example, this AV pair activates Cisco’s multiple named ip address pools feature during IP authorization (during PPP IPCP address assignment):

 

cisco-avpair= ”ip:addr-pool=first“

 

This example shows how to provide a user logging in from a switch module with immediate access to privileged EXEC commands:

 

cisco-avpair= ”shell:priv-lvl=15“

 

This example shows how to specify an authorized VLAN in the RADIUS server database:

 

cisco-avpair= ”tunnel-type(#64)=VLAN(13)”
cisco-avpair= ”tunnel-medium-type(#65)=802 media(6)”
cisco-avpair= ”tunnel-private-group-ID(#81)=vlanid”

 

This example shows how to apply an input ACL in ASCII format to an interface for the duration of this connection:

 

cisco-avpair= “ip:inacl#1=deny ip 10.10.10.10 0.0.255.255 20.20.20.20 255.255.0.0”
cisco-avpair= “ip:inacl#2=deny ip 10.10.10.10 0.0.255.255 any”
cisco-avpair= “mac:inacl#3=deny any any decnet-iv”

 

This example shows how to apply an output ACL in ASCII format to an interface for the duration of this connection:

 

cisco-avpair= “ip:outacl#2=deny ip 10.10.10.10 0.0.255.255 any”

 

Other vendors have their own unique vendor-IDs, options, and associated VSAs. For more information about vendor-IDs and VSAs, see RFC 2138, “Remote Authentication Dial-In User Service (RADIUS).”

Beginning in privileged EXEC mode, follow these steps to configure the switch module to recognize and use VSAs:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable the switch module to recognize and use VSAs as defined by RADIUS IETF attribute 26.

  • (Optional) Use the accounting keyword to limit the set of recognized vendor-specific attributes to only accounting attributes.
  • (Optional) Use the authentication keyword to limit the set of recognized vendor-specific attributes to only authentication attributes.

If you enter this command without keywords, both accounting and authentication vendor-specific attributes are used.

radius-server vsa send [ accounting | authentication ]

Step 3

Return to privileged EXEC mode.

end

Step 4

Verify your settings.

show running-config

Step 5

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

For a complete list of RADIUS attributes or more information about vendor-specific attribute 26, see the “RADIUS Attributes” appendix in the Cisco IOS Security Configuration Guide, Release 12.2.

Configuring the Switch Module for Vendor-Proprietary RADIUS Server Communication

Although an IETF draft standard for RADIUS specifies a method for communicating vendor-proprietary information between the switch module and the RADIUS server, some vendors have extended the RADIUS attribute set in a unique way. Cisco IOS software supports a subset of vendor-proprietary RADIUS attributes.

As mentioned earlier, to configure RADIUS (whether vendor-proprietary or IETF draft-compliant), you must specify the host running the RADIUS server daemon and the secret text string it shares with the switch module. You specify the RADIUS host and secret text string by using the radius-server global configuration commands.

Beginning in privileged EXEC mode, follow these steps to specify a vendor-proprietary RADIUS server host and a shared secret text string:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Specify the IP address or hostname of the remote RADIUS server host and identify that it is using a vendor-proprietary implementation of RADIUS.

radius-server host {hostname | ip-address} non-standard

Step 3

Specify the shared secret text string used between the switch module and the vendor-proprietary RADIUS server. the switch module and the RADIUS server use this text string to encrypt passwords and exchange responses.

Note The key is a text string that must match the encryption key used on the RADIUS server. Leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in your key, do not enclose the key in quotation marks unless the quotation marks are part of the key.

radius-server key string

Step 4

Return to privileged EXEC mode.

end

Step 5

Verify your settings.

show running-config

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To delete the vendor-proprietary RADIUS host, use the no radius-server host {hostname | ip-address} non-standard global configuration command. To disable the key, use the no radius-server key global configuration command.

This example shows how to specify a vendor-proprietary RADIUS host and to use a secret key of rad124 between the switch module and the server:

 

Switch(config)# radius-server host 172.20.30.15 nonstandard
Switch(config)# radius-server key rad124

 

Configuring RADIUS Server Load Balancing

This feature allows access and authentication requests to be evenly across all RADIUS servers in a server group. For more information, see the “RADIUS Server Load Balancing” chapter of the “Cisco IOS Security Configuration Guide”, Release 12.2:

http://www.ciscosystems.com/en/US/docs/ios/12_2sb/feature/guide/sbrdldbl.html

Displaying the RADIUS Configuration

To display the RADIUS configuration, use the show running-config p rivileged EXEC command.

Controlling Switch Module Access with Kerberos

This section describes how to enable and configure the Kerberos security system, which authenticates requests for network resources by using a trusted third party. To use this feature, the cryptographic (that is, supports encryption) version of the switch module software must be installed on your switch module. You must obtain authorization to use this feature and to download the cryptographic software files from Cisco.com. For more information, see the release notes for this release.

These sections contain this information:

For Kerberos configuration examples, see the “Kerberos Configuration Examples” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide, Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrad.html

For complete syntax and usage information for the commands used in this section, see the “Kerberos Commands” section in the “Security Server Protocols” chapter of the Cisco IOS Security Command Reference, Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/fsecur_r.html

Note In the Kerberos configuration examples and in the Cisco IOS Security Command Reference, Release 12.2, the trusted third party can be a CGR 2010 ESM that supports Kerberos, that is configured as a network security server, and that can authenticate users by using the Kerberos protocol.

Understanding Kerberos

Kerberos is a secret-key network authentication protocol, which was developed at the Massachusetts Institute of Technology (MIT). It uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication and authenticates requests for network resources. Kerberos uses the concept of a trusted third party to perform secure verification of users and services. This trusted third party is called the key distribution center (KDC).

Kerberos verifies that users are who they claim to be and the network services that they use are what the services claim to be. To do this, a KDC or trusted Kerberos server issues tickets to users. These tickets, which have a limited lifespan, are stored in user credential caches. The Kerberos server uses the tickets instead of usernames and passwords to authenticate users and network services.

Note A Kerberos server can be a CGR 2010 ESM that is configured as a network security server and that can authenticate users by using the Kerberos protocol.

The Kerberos credential scheme uses a process called single logon. This process authenticates a user once and then allows secure authentication (without encrypting another password) wherever that user credential is accepted.

This software release supports Kerberos 5, which allows organizations that are already using Kerberos 5 to use the same Kerberos authentication database on the KDC that they are already using on their other network hosts (such as UNIX servers and PCs).

In this software release, Kerberos supports these network services:

  • Telnet
  • rlogin
  • rsh (Remote Shell Protocol)

Table 7-2 lists the common Kerberos-related terms and definitions:

 

Table 7-2 Kerberos Terms

Term
Definition

Authentication

A process by which a user or service identifies itself to another service. For example, a client can authenticate to a switch module or a switch module can authenticate to another switch module.

Authorization

A means by which the switch module identifies what privileges the user has in a network or on the switch module and what actions the user can perform.

Credential

A general term that refers to authentication tickets, such as TGTs (ticket granting tickets) and service credentials. Kerberos credentials verify the identity of a user or service. If a network service decides to trust the Kerberos server that issued a ticket, it can be used in place of re-entering a username and password. Credentials have a default lifespan of eight hours.

Instance

An authorization level label for Kerberos principals. Most Kerberos principals are of the form user@REALM (for example, smith@EXAMPLE.COM). A Kerberos principal with a Kerberos instance has the form user/instance@REALM (for example, smith/admin@EXAMPLE.COM). The Kerberos instance can be used to specify the authorization level for the user if authentication is successful. The server of each network service might implement and enforce the authorization mappings of Kerberos instances but is not required to do so.

Note The Kerberos principal and instance names must be in all lowercase characters.

Note The Kerberos realm name must be in all uppercase characters.

KDC

Key distribution center that consists of a Kerberos server and database program that is running on a network host.

Kerberized

A term that describes applications and services that have been modified to support the Kerberos credential infrastructure.

Kerberos realm

A domain consisting of users, hosts, and network services that are registered to a Kerberos server. The Kerberos server is trusted to verify the identity of a user or network service to another user or network service.

Note The Kerberos realm name must be in all uppercase characters.

Kerberos server

A daemon that is running on a network host. Users and network services register their identity with the Kerberos server. Network services query the Kerberos server to authenticate to other network services.

KEYTAB

Key table. A password that a network service shares with the KDC. In Kerberos 5 and later Kerberos versions, the network service authenticates an encrypted service credential by using the KEYTAB to decrypt it. In Kerberos versions earlier than Kerberos 5, KEYTAB is referred to as SRVTAB (server table).

Principal

Also known as a Kerberos identity, this is who you are or what a service is according to the Kerberos server.

Note The Kerberos principal name must be in all lowercase characters.

Service credential

A credential for a network service. When issued from the KDC, this credential is encrypted with the password shared by the network service and the KDC. The password is also shared with the user TGT.

SRVTAB

Server table. A password that a network service shares with the KDC. In Kerberos 5 or later Kerberos versions, SRVTAB is referred to as KEYTAB.

TGT

Ticket granting ticket that is a credential that the KDC issues to authenticated users. When users receive a TGT, they can authenticate to network services within the Kerberos realm represented by the KDC.

Kerberos Operation

A Kerberos server can be a CGR 2010 ESM that is configured as a network security server and that can authenticate remote users by using the Kerberos protocol. Although you can customize Kerberos in a number of ways, remote users attempting to access network services must pass through three layers of security before they can access network services.

To authenticate to network services by using a CGR 2010 ESM as a Kerberos server, remote users must follow these steps:

1. Authenticating to a Boundary Switch Module

2. Obtaining a TGT from a KDC

3. Authenticating to Network Services

Authenticating to a Boundary Switch Module

This section describes the first layer of security through which a remote user must pass. The user must first authenticate to the boundary switch module. The following process then occurs:

1. The user opens an un-Kerberized Telnet connection to the boundary switch module.

2. The switch module prompts the user for a username and password.

3. The switch module requests a TGT from the KDC for this user.

4. The KDC sends an encrypted TGT that includes the user identity to the switch module.

5. The switch module attempts to decrypt the TGT by using the password that the user entered.

  • If the decryption is successful, the user is authenticated to the switch module.
  • If the decryption is not successful, the user repeats Step 2 either by re-entering the username and password (noting if Caps Lock or Num Lock is on or off) or by entering a different username and password.

A remote user who initiates a un-Kerberized Telnet session and authenticates to a boundary switch module is inside the firewall, but the user must still authenticate directly to the KDC before getting access to the network services. The user must authenticate to the KDC because the TGT that the KDC issues is stored on the switch module and cannot be used for additional authentication until the user logs on to the switch module.

Obtaining a TGT from a KDC

This section describes the second layer of security through which a remote user must pass. The user must now authenticate to a KDC and obtain a TGT from the KDC to access network services.

For instructions about how to authenticate to a KDC, see the “Obtaining a TGT from a KDC” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide, Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfkerb.html

Authenticating to Network Services

This section describes the third layer of security through which a remote user must pass. The user with a TGT must now authenticate to the network services in a Kerberos realm.

For instructions about how to authenticate to a network service, see the “Authenticating to Network Services” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide, Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfkerb.html

Configuring Kerberos

So that remote users can authenticate to network services, you must configure the hosts and the KDC in the Kerberos realm to communicate and mutually authenticate users and network services. To do this, you must identify them to each other. You add entries for the hosts to the Kerberos database on the KDC and add KEYTAB files generated by the KDC to all hosts in the Kerberos realm. You also create entries for the users in the KDC database.

When you add or create entries for the hosts and users, follow these guidelines:

  • The Kerberos principal name must be in all lowercase characters
  • The Kerberos instance name must be in all lowercase characters
  • The Kerberos realm name must be in all uppercase characters

Note A Kerberos server can be a CGR 2010 ESM that is configured as a network security server and that can authenticate users by using the Kerberos protocol.

To set up a Kerberos-authenticated server-client system, follow these steps:

  • Configure the KDC by using Kerberos commands
  • Configure the switch module to use the Kerberos protocol

For instructions, see the “Kerberos Configuration Task List” section in the “Security Server Protocols” chapter of the Cisco IOS Security Configuration Guide, Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfkerb.html

Configuring the Switch Module for Local Authentication and Authorization

You can configure AAA to operate without a server by setting the switch module to implement AAA in local mode. The switch module then handles authentication and authorization. No accounting is available in this configuration.

Beginning in privileged EXEC mode, follow these steps to configure the switch module for local AAA:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Enable AAA.

aaa new-model

Step 3

Set the login authentication to use the local username database. The default keyword applies the local user database authentication to all ports.

aaa authentication login default local

Step 4

Configure user AAA authorization, check the local database, and allow the user to run an EXEC shell.

aaa authorization exec local

Step 5

Configure user AAA authorization for all network-related service requests.

aaa authorization network local

Step 6

Enter the local database, and establish a username-based authentication system.

Repeat this command for each user.

  • For name, specify the user ID as one word. Spaces and quotation marks are not allowed.
  • (Optional) For level, specify the privilege level the user has after gaining access. The range is 0 to 15. Level 15 gives privileged EXEC mode access. Level 0 gives user EXEC mode access.
  • For encryption-type, enter 0 to specify that an unencrypted password follows. Enter 7 to specify that a hidden password follows.
  • For password, specify the password the user must enter to gain access to the switch module. The password must be from 1 to 25 characters, can contain embedded spaces, and must be the last option specified in the username command.

username name [ privilege level ] { password encryption-type password }

Step 7

Return to privileged EXEC mode.

end

Step 8

Verify your entries.

show running-config

Step 9

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To disable AAA, use the no aaa new-model global configuration command. To disable authorization, use the no aaa authorization { network | exec } method1 global configuration command.

Configuring the Switch Module for Secure Shell

This section describes how to configure the Secure Shell (SSH) feature. To use this feature, you must install the cryptographic (encrypted) software image on your switch module. You must obtain authorization to use this feature and to download the cryptographic software files from Cisco.com. For more information, see the release notes for this release.

These sections contain this information:

For SSH configuration examples, see the “SSH Configuration Examples” section in the “Configuring Secure Shell” chapter of the Cisco IOS Security Configuration Guide, Cisco IOS Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfssh.html#wp1001292

Note For complete syntax and usage information for the commands used in this section, see the command reference for this release and the command reference for Cisco IOS Release 12.2 at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/fsecur_r.html

Understanding SSH

SSH is a protocol that provides a secure, remote connection to a device. SSH provides more security for remote connections than Telnet does by providing strong encryption when a device is authenticated. This software release supports SSH Version 1 (SSHv1) and SSH Version 2 (SSHv2).

This section consists of these topics:

SSH Servers, Integrated Clients, and Supported Versions

The SSH feature has an SSH server and an SSH integrated client, which are applications that run on the switch module. You can use an SSH client to connect to a switch module running the SSH server. The SSH server works with the SSH client supported in this release and with non-Cisco SSH clients. The SSH client also works with the SSH server supported in this release and with non-Cisco SSH servers.

The switch module supports an SSHv1 or an SSHv2 server, and the switch module supports an SSHv1 client.

SSH supports the Data Encryption Standard (DES) encryption algorithm, the Triple DES (3DES) encryption algorithm, and password-based user authentication.

SSH also supports these user authentication methods:

Note This software release does not support IP Security (IPSec).

Limitations

These limitations apply to SSH:

  • The switch module supports Rivest, Shamir, and Adelman (RSA) authentication.
  • SSH supports only the execution-shell application.
  • The SSH server and the SSH client are supported only on DES (56-bit) and 3DES (168-bit) data encryption software.
  • The switch module supports the Advanced Encryption Standard (AES) encryption algorithm with a 128-bit key, 192-bit key, or 256-bit key. However, symmetric cipher AES to encrypt the keys is not supported.

Configuring SSH

This section has this configuration information:

Configuration Guidelines

Follow these guidelines when configuring the switch module as an SSH server or SSH client:

  • An RSA key pair generated by a SSHv1 server can be used by an SSHv2 server, and the reverse.
  • If you get CLI error messages after entering the crypto key generate rsa global configuration command, an RSA key pair has not been generated. Reconfigure the hostname and domain, and then enter the crypto key generate rsa command. For more information, see the “Setting Up the Switch Module to Run SSH” section.
  • When generating the RSA key pair, the message No host name specified might appear. If it does, you must configure a hostname by using the hostname global configuration command.
  • When generating the RSA key pair, the message No domain specified might appear. If it does, you must configure an IP domain name by using the ip domain-name global configuration command.
  • When configuring the local authentication and authorization authentication method, make sure that AAA is disabled on the console.

Setting Up the Switch Module to Run SSH

Follow these steps to set up your switch module to run SSH:

1. Download the cryptographic software image from Cisco.com. This step is required. For more information, see the release notes for this release.

2. Configure a hostname and IP domain name for the switch module. Follow this procedure only if you are configuring the switch module as an SSH server.

3. Generate an RSA key pair for the switch module, which automatically enables SSH. Follow this procedure only if you are configuring the switch module as an SSH server.

4. Configure user authentication for local or remote access. This step is required. For more information, see the “Configuring the Switch Module for Local Authentication and Authorization” section.

Beginning in privileged EXEC mode, follow these steps to configure a hostname and an IP domain name and to generate an RSA key pair. This procedure is required if you are configuring the switch module as an SSH server.

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

Configure a hostname for your switch module.

hostname hostname

Step 3

Configure a host domain for your switch module.

ip domain-name domain_name

Step 4

Enable the SSH server for local and remote authentication on the switch module and generate an RSA key pair.

We recommend that a minimum modulus size of 1024 bits.

When you generate RSA keys, you are prompted to enter a modulus length. A longer modulus length might be more secure, but it takes longer to generate and to use.

crypto key generate rsa

Step 5

Return to privileged EXEC mode.

end

Step 6

Show the version and configuration information for your SSH server.

Show the status of the SSH server on the switch module.

show ip ssh

or

show ssh

Step 7

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To delete the RSA key pair, use the crypto key zeroize rsa global configuration command. After the RSA key pair is deleted, the SSH server is automatically disabled.

Configuring the SSH Server

Beginning in privileged EXEC mode, follow these steps to configure the SSH server:

 

Step
Command

Step 1

Enter global configuration mode.

configure terminal

Step 2

(Optional) Configure the switch module to run SSH Version 1 or SSH Version 2.

  • 1 —Configure the switch module to run SSH Version 1.
  • 2 —Configure the switch module to run SSH Version 2.

If you do not enter this command or do not specify a keyword, the SSH server selects the latest SSH version supported by the SSH client. For example, if the SSH client supports SSHv1 and SSHv2, the SSH server selects SSHv2.

ip ssh version [ 1 | 2 ]

Step 3

Configure the SSH control parameters:

  • Specify the time-out value in seconds; the default is 120 seconds. The range is 0 to 120 seconds. This parameter applies to the SSH negotiation phase. After the connection is established, the switch module uses the default time-out values of the CLI-based sessions.
  • By default, up to five simultaneous, encrypted SSH connections for multiple CLI-based sessions over the network are available (session 0 to session 4). After the execution shell starts, the CLI-based session time-out value returns to the default of 10 minutes.
  • Specify the number of times that a client can re-authenticate to the server. The default is 3; the range is 0 to 5.

Repeat this step when configuring both parameters.

ip ssh { timeout seconds | authentication-retries number }

Step 4

Return to privileged EXEC mode.

end

Step 5

Show the version and configuration information for your SSH server.

Show the status of the SSH server connections on the switch module.

show ip ssh

or

show ssh

Step 6

(Optional) Save your entries in the configuration file.

copy running-config startup-config

 

To return to the default SSH control parameters, use the no ip ssh { timeout | authentication-retries } global configuration command.

Displaying the SSH Configuration and Status

To display the SSH server configuration and status, use one or more of the privileged EXEC commands in Table 7-3 :

 

Table 7-3 Commands for Displaying the SSH Server Configuration and Status

Command
Description

show ip ssh

Shows the version and configuration information for the SSH server.

show ssh

Shows the status of the SSH server.

For more information about these commands, see the “ Secure Shell Commands ” section in the “Other Security Features” chapter of the Cisco IOS Security Command Reference, Cisco IOS Release 12.2, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/srfpass.html

Configuring the Switch Module for Secure Copy Protocol

The Secure Copy Protocol (SCP) feature provides a secure and authenticated method for copying switch module configurations or switch module image files. SCP relies on Secure Shell (SSH), an application and a protocol that provides a secure replacement for the Berkeley r-tools.

For SSH to work, the switch module needs an RSA public/private key pair. This is the same with SCP, which relies on SSH for its secure transport.

Because SSH also relies on AAA authentication, and SCP relies further on AAA authorization, correct configuration is necessary.

  • Before enabling SCP, you must correctly configure SSH, authentication, and authorization on the switch module
  • Because SCP relies on SSH for its secure transport, the router must have an Rivest, Shamir, and Adelman (RSA) key pair

Note When using SCP, you cannot enter the password into the copy command. You must enter the password when prompted.

Information About Secure Copy

To configure the Secure Copy feature, you should understand these concepts.

  • The behavior of SCP is similar to that of remote copy (rcp), which comes from the Berkeley r-tools suite, except that SCP relies on SSH for security. SCP also requires that authentication, authorization, and accounting (AAA) authorization be configured so the router can determine whether the user has the correct privilege level.
  • A user who has appropriate authorization can use SCP to copy any file in the Cisco IOS File System (IFS) to and from a switch module by using the copy command. An authorized administrator can also do this from a workstation.

For more information on how to configure and verify SCP, see the “Secure Copy Protocol” chapter of the Cisco IOS New Features, Cisco IOS Release 12.2T, at this URL:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftscp.html