Cisco Nexus 5000 Series NX-OS Software Configuration Guide

RADIUS Network Environments

RADIUS can be implemented in a variety of network environments that require high levels of security while maintaining network access for remote users.

You can use RADIUS in the following network environments that require access security:

• Networks with multiple-vendor network devices, each supporting RADIUS.

For example, network devices from several vendors can use a single RADIUS server-based security database.

• Networks already using RADIUS.

You can add a Nexus 5000 Series switch with RADIUS to the network. This action might be the first step when you make a transition to a AAA server.

• Networks that require resource accounting.

You can use RADIUS accounting independent of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, indicating the amount of resources (such as time, packets, bytes, and so on) used during the session. An Internet service provider (ISP) might use a freeware-based version of the RADIUS access control and accounting software to meet special security and billing needs.

• Networks that support authentication profiles.

Using the RADIUS server in your network, you can configure AAA authentication and set up per-user profiles. Per-user profiles enable the Nexus 5000 Series switch to better manage ports using their existing RADIUS solutions and to efficiently manage shared resources to offer different service-level agreements.

RADIUS Operation

When a user attempts to log in and authenticate to a Nexus 5000 Series switch using RADIUS, the following process occurs:

1. The user is prompted for and enters 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 the following responses from the RADIUS server:

• ACCEPT—The user is authenticated.
• REJECT—The user is not authenticated and is prompted to reenter the username and password, or access is denied.
• CHALLENGE—A challenge is issued by the RADIUS server. The challenge collects additional data from the user.
• CHANGE PASSWORD—A request is issued by the RADIUS server, asking the user to select a new password.

The ACCEPT or REJECT response is bundled with additional data that is used for EXEC or network authorization. You must first complete RADIUS authentication before using RADIUS authorization. The additional data included with the ACCEPT or REJECT packets consists of the following:

• Services that the user can access, including Telnet, rlogin, or local-area transport (LAT) connections, and Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or EXEC services.
• Connection parameters, including the host or client IPv4 or IPv6 address, access list, and user timeouts.

RADIUS Server Monitoring

An unresponsive RADIUS server can cause delay in processing of AAA requests. You can configure the Nexus 5000 Series switch to periodically monitor a RADIUS server to check whether it is responding (or alive) to save time in processing AAA requests. The Nexus 5000 Series switch marks unresponsive RADIUS servers as dead and does not send AAA requests to any dead RADIUS servers. The switch periodically monitors the dead RADIUS servers and brings them to the alive state once they respond. This monitoring process verifies that a RADIUS server is in a working state before real AAA requests are sent its way. Whenever a RADIUS server changes to the dead or alive state, a Simple Network Management Protocol (SNMP) trap is generated and the Nexus 5000 Series switch displays an error message that a failure is taking place. See Figure 1-1.

Figure 1-1 RADIUS Server States

Note The monitoring interval for alive servers and dead servers are different and can be configured by the user. The RADIUS server monitoring is performed by sending a test authentication request to the RADIUS server.

Vendor-Specific Attributes

The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific attributes (VSA’s) between the network access server and the RADIUS server. The IETF uses attribute 26. VSAs allow vendors to support their own extended attributes that are not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option using the format recommended in the specification. The Cisco vendor ID is 9, and the supported option is vendor type 1, which is named cisco-av-pair. The value is a string with the following format:

The protocol is a Cisco attribute for a particular type of authorization, the separator is an equal sign (=) for mandatory attributes, and an asterisk ( *) indicates optional attributes.

When you use RADIUS servers for authentication on a Nexus 5000 Series switch, the RADIUS protocol directs the RADIUS server to return user attributes, such as authorization information, along with authentication results. This authorization information is specified through VSAs.

The following VSA protocol options are supported by the Nexus 5000 Series switch:

• Shell— Used in access-accept packets to provide user profile information.
• Accounting— Used in accounting-request packets. If a value contains any white spaces, you should enclose the value within double quotation marks.

The Nexus 5000 Series switch supports the following attributes:

• roles—Lists all the roles to which the user belongs. The value field is a string that lists the role names delimited by white space.
• accountinginfo—Stores accounting information in addition to the attributes covered by a standard RADIUS accounting protocol. This attribute is sent only in the VSA portion of the Account-Request frames from the RADIUS client on the switch. It can be used only with the accounting protocol data units (PDUs).

Configuring RADIUS Server Hosts

You must configure the IPv4 or IPv6 address or the host name for each RADIUS server that you want to use for authentication. All RADIUS server hosts are added to the default RADIUS server group. You can configure up to 64 RADIUS servers.

To configure a RADIUS server host, perform this task:

The following example shows how to configure a RADIUS server host:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring Global Preshared Keys

You can configure preshared keys at the global level for all servers used by the Nexus 5000 Series switch. A preshared key is a shared secret text string between the Nexus 5000 Series switch and the RADIUS server hosts.

To configure global preshared keys, obtain the preshared key values for the remote RADIUS servers and perform this task:

:

The following example shows how to obtain the preshared key values for a remote RADIUS server:

switch# configure terminal

switch(config)# radius-server key 0 QsEfThUkO

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring RADIUS Server Preshared Keys

You can configure preshared keys for a RADIUS server. A preshared key is a shared secret text string between the Nexus 5000 Series switch and the RADIUS server host.

To configure radius server preshared keys, obtain the preshared key values for the remote RADIUS servers and perform this task:

:

The following example shows how to configure a preshared keys for a RADIUS server:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1 key 0 PlIjUhYg

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring RADIUS Server Groups

You can specify one or more remote AAA servers for authentication using server groups. All members of a group must belong to the RADIUS protocol. The servers are tried in the same order in which you configure them.

You can configure these server groups at any time but they only take effect when you apply them to an AAA service. For information on AAA services, see the “Remote AAA Services” section.

To configure radius server groups, perform this task:

:

The following example shows how to configure a RADIUS server group:

switch(config)# copy running-config startup-config

Allowing Users to Specify a RADIUS Server at Login

Note By default, the Nexus 5000 Series switch forwards an authentication request based on the default AAA authentication method. You can configure the Nexus 5000 Series switch to allow the user to specify a VRF and RADIUS server to send the authenticate request by enabling the directed-request option. If you enable this option, the user can log in as username@hostname, where hostname is the name of a configured RADIUS server. User specified logins are only supported for Telnet sessions.

To allow users to specify a RADIUS server at login, perform this task:

Configuring the Global RADIUS Transmission Retry Count and Timeout Interval

You can configure a global retransmission retry count and timeout interval for all RADIUS servers. By default, a switch retries transmission to a RADIUS server only once before reverting to local authentication. You can increase this number up to a maximum of five retries per server. The timeout interval determines how long the Nexus 5000 Series switch waits for responses from RADIUS servers before declaring a timeout failure.

To configure the global RADIUS transmission retry count and timeout interval, perform this task:

:

Configuring the RADIUS Transmission Retry Count and Timeout Interval for a Server

By default, a Nexus 5000 Series switch retries transmission to a RADIUS server only once before reverting to local authentication. You can increase this number up to a maximum of five retries per server. You can also set a timeout interval that the Nexus 5000 Series switch waits for responses from RADIUS servers before declaring a timeout failure.

To configure RADIUS transmission retry count and timeout interval for a server, perform this task:

The following example shows how to configure RADIUS transmission retry count and timeout interval for a server:

switch# configure terminal

switch(config)# radius-server host server1 retransmit 3

switch(config)# radius-server host server1 timeout 10

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring Accounting and Authentication Attributes for RADIUS Servers

You can specify that a RADIUS server is to be used only for accounting purposes or only for authentication purposes. By default, RADIUS servers are used for both accounting and authentication. You can also specify the destination UDP port numbers where RADIUS accounting and authentication messages should be sent.

To configure the accounting and authentication attributes for RADIUS servers, perform this task:

The following example shows how to configure the accounting and authentication attributes for a RADIUS server:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1 acct-port 2004

switch(config)# radius-server host 10.10.1.1 accounting

switch(config)# radius-server host 10.10.2.2 auth-port 2005

switch(config)# radius-server host 10.10.2.2 authentication

switch(config)# exit

switch(config)# show radius-server

switch# copy running-config startup-config

Configuring Periodic RADIUS Server Monitoring

You can monitor the availability of RADIUS servers. These parameters include the username and password to use for the server and an idle timer. The idle timer specifies the interval during which a RADIUS server receives no requests before the Nexus 5000 Series switch sends out a test packet. You can configure this option to test servers periodically.

Note For security reasons, we recommend that you do not configure a test username that is the same as an existing user in the RADIUS database.

The test idle timer specifies the interval during which a RADIUS server receives no requests before the Nexus 5000 Series switch sends out a test packet.

Note The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, the Nexus 5000 Series switch does not perform periodic RADIUS server monitoring.

To configure periodic RADIUS server monitoring, perform this task:

The following example shows how to configure periodic RADIUS server monitoring:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1 test username user1 password Ur2Gd2BH idle-time 3

switch(config)# radius-server deadtime 5

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring the Dead-Time Interval

You can configure the dead-time interval for all RADIUS servers. The dead-time interval specifies the time that the Nexus 5000 Series switch waits after declaring a RADIUS server is dead, before sending out a test packet to determine if the server is now alive. The default value is 0 minutes.

Note When the dead-time interval is 0 minutes, RADIUS servers are not marked as dead even if they are not responding. You can configure the dead-time interval for a RADIUS server group (see the “Configuring RADIUS Server Groups” section).

To configure dead time interval, perform this task:

Manually Monitoring RADIUS Servers or Groups

To manually send a test message to a RADIUS server or to a server group, perform this task:

The following example shows how to manually send a test message to a RADIUS server:

switch# test aaa server radius 10.10.1.1 user1 Ur2Gd2BH

switch# test aaa group RadGroup user2 As3He3CI