Cisco supports RADIUS under its authentication, authorization, and accounting (AAA) security paradigm. RADIUS can be used with other AAA security protocols such as TACACS+, Kerberos, and local username lookup. RADIUS is supported on all Cisco platforms, but some RADIUS-supported features run only on specified platforms.

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

Use RADIUS in the following 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 validate users and grant access to network resources.
• Networks already using RADIUS. You can add a Cisco device with RADIUS to the network. This might be the first step when you make a transition to a TACACS+ server.
• Networks in which a 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 a single protocol such as PPP. For example, when a user logs in, RADIUS identifies this user as having authorization to run PPP using the IP address 10.2.3.4 and the defined access list is started.
• 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, and bytes) used during the session. An ISP might use a freeware-based version of RADIUS access control and accounting software to meet special security and billing needs.
• Networks that support preauthentication. Using the RADIUS server in your network, you can configure AAA preauthentication and set up the preauthentication profiles. Preauthentication enables service providers to better manage ports using their existing RADIUS solutions, and to efficiently manage the use of shared resources to offer differing service-level agreements.

RADIUS is not suitable in these network security situations:

• Multiprotocol access environments. RADIUS does not support the following protocols:

  • AppleTalk Remote Access (ARA)
  • NetBIOS Frame Control Protocol (NBFCP)
  • NetWare Asynchronous Services Interface (NASI)
  • X.25 Packet Assemblers/Disassemblers (PAD) connections
• Device-to-device 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 RADIUS authentication.
• Networks using a variety of services. RADIUS generally binds a user to one service model.

When a user attempts to log in and authenticate to an access server using RADIUS, the following steps occur:

1. The user is prompted to enter the 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:

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

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 connections such as Telnet, rlogin, or local-area transport (LAT), and services such as PPP, Serial Line Protocol (SLIP), or EXEC services.
• Connection parameters, including the host or client IP address, access list, and user timeouts.

The network access server monitors the RADIUS authorization and accounting functions defined by RADIUS attributes in each user profile:

RADIUS attributes are configured in the RADIUS preauthentication profiles to specify preauthentication behavior. In addition to configuring preauthentication on your Cisco device, you must set up the preauthentication profiles on the RADIUS server.

After you have identified the RADIUS server and defined the RADIUS authentication key, you must define method lists for RADIUS authentication. Because RADIUS authentication is facilitated through AAA, you must enter the aaa authentication command, specifying RADIUS as the authentication method.

AAA authorization lets you set parameters that restrict a user’s access to the network. Authorization using RADIUS provides one method for remote access control, including one-time authorization or authorization for each service, per-user account list and profile, user group support, and support of IP, IPX, AppleTalk Remote Access (ARA), and Telnet. Because RADIUS authorization is facilitated through AAA, you must enter the aaa authorization command, specifying RADIUS as the authorization method.

The AAA accounting feature enables you to track the services users are accessing and the amount of network resources they are consuming. Because RADIUS accounting is facilitated through AAA, you must enter the aaa accounting command, specifying RADIUS as the accounting method.

To enable the network access server (NAS) to attempt more than one login host when trying to connect a dial-in user, you can enter as many as three Login-IP-Host entries in the user’s profile on the RADIUS server. The following example shows that three Login-IP-Host instances are configured for the user user1, and that TCP-Clear is used for the connection:

user1 Password = xyz
        Service-Type = Login,
        Login-Service = TCP-Clear,
        Login-IP-Host = 10.0.0.0,
        Login-IP-Host = 10.2.2.2,
        Login-IP-Host = 10.255.255.255,
        Login-TCP-Port = 23

The order in which the hosts are entered is the order in which they are attempted. Use the ip tcp synwait-time command to set the number of seconds that the NAS waits before trying to connect to the next host on the list; the default is 30 seconds.

Your RADIUS server might permit more than three Login-IP-Host entries; however, the NAS supports only three hosts in Access-Accept packets.

To control whether user responses to Access-Challenge packets are echoed to the screen, you can configure the Prompt attribute in the user profile on the RADIUS server. This attribute is included only in Access-Challenge packets. The following example shows the Prompt attribute set to No-Echo, which prevents the user’s responses from echoing:

user1 Password = xyz 
Service-Type = Login, 
Login-Service = Telnet, 
Prompt = No-Echo, 
Login-IP-Host = 172.31.255.255 

To allow user responses to echo, set the attribute to Echo. If the Prompt attribute is not included in the user profile, responses are echoed by default.

This attribute overrides the behavior of the radius-server challenge-noecho command configured on the access server. For example, if the access server is configured to suppress echoing, but the individual user profile allows echoing, the user responses are echoed.

Note	If you want to use the Prompt attribute, your RADIUS server must be configured to support Access-Challenge packets.

The IETF standard specifies a method for communicating vendor-specific information between the network access server 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 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; protocols that can be used include IP, Internetwork Packet Exchange (IPX), VPDN, VoIP, Secure Shell (SSH), Resource Reservation Protocol (RSVP), Serial Interface Processor (SIP), AirNet, and Outbound. “Attribute” and “value” are an appropriate AV pair defined in the Cisco TACACS+ specification, and “sep” is “=” for mandatory attributes and “*” for optional attributes, allowing the full set of features available for TACACS+ authorization to also be used for RADIUS.

For example, the following AV pair causes Cisco’s “multiple named ip address pools” feature to be activated during IP authorization (during PPP’s Internet Protocol Control Protocol (IPCP) address assignment):

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

If you insert an “*”, the AV pair “ip:addr-pool=first” becomes optional. Note that any AV pair can be made optional:

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

The following example shows how to cause a user logging in from a network access server to have immediate access to EXEC commands:

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

Other vendors have their own unique vendor IDs, options, and associated VSAs.

Some vendor-proprietary implementations of RADIUS let the user define static routes and IP pool definitions on the RADIUS server instead of on each individual network access server in the network. Each network access server then queries the RADIUS server for static route and IP pool information.

To have the Cisco device or access server query the RADIUS server for static routes and IP pool definitions when the device starts up, use the radius-server configure-nas command.

Because the radius-server configure-nas command is performed when the Cisco devcie starts up, it does not take effect until you enter a copy system:running-config nvram:startup-config command.

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

To configure RADIUS (whether vendor-proprietary or IETF compliant), you must use the radius-server commands to specify the host running the RADIUS server daemon and the secret text string it shares with the Cisco device. To identify that the RADIUS server is using a vendor-proprietary implementation of RADIUS, use the radius-server host non-standard command. Vendor-proprietary attributes are not supported unless you use the radius-server host non-standard command.

Note

To configure an IPv4 or IPv6 RADIUS server, use the commands as mentioned below: If you have configured an IPv4 RADIUS server, you can use either the radius-server host command or the radius server name command. If you have configured an IPv6 RADIUS server, use the radius server name command. For more information about the radius server command, see Cisco IOS Security Command Reference: Commands M to R.

1.    enable


2.    configure terminal


3.    radius-server vsa send [accounting | authentication]


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


5.    radius-server key {0 string | 7 string | string}


6.    exit

Device> enable

Device# configure terminal

Device(config)# radius-server vsa send

Device(config)# radius-server host host1 non-standard

Device(config)# radius-server key myRaDIUSpassword

Device(config)# exit

Sometimes PPP or login authentication occurs on an interface that is different from the interface on which the call itself comes in. For example, in a V.120 ISDN call, login or PPP authentication occurs on a virtual asynchronous interface “ttt”, but the call itself occurs on one of the channels of the ISDN interface.

The radius-server attribute nas-port extended command configures RADIUS to expand the size of the NAS-Port attribute (RADIUS IETF attribute 5) field to 32 bits. The upper 16 bits of the NAS-Port attribute display the type and number of the controlling interface; the lower 16 bits indicate the interface undergoing authentication.

Note	The radius-server attribute nas-port format command replaces the radius-server extended-portnames command and the radius-server attribute nas-port extended command.

1.    enable


2.    configure terminal


3.    radius-server configure-nas


4.    radius-server attribute nas-port format


5.    exit

Device> enable

Device# configure terminal

Device(config)# radius-server configure-nas

Device(config)# radius-server attribute nas-port format

Device(config)# exit

1.    enable


2.    configure terminal


3.    radius-server vsa send [accounting | authentication]


4.    aaa nas port extended


5.    exit

Device> enable

Device# configure terminal

Device(config)# radius-server vsa send

Device(config)# aaa nas port extended

Device(config)# exit

1.    enable


2.    configure terminal


3.    aaa new-model


4.    aaa route download time


5.    aaa authorization configuration default


6.    interface dialer number


7.    dialer aaa


8.    dialer aaa suffix suffix password password


9.    exit

Device> enable

Device# configure terminal

Device(config)# aaa new-model

Device(config)# aaa route download 450

Device(config)# aaa authorization configuration default

Device(config)# interface dialer 1

Device(config-if)# dialer aaa

Device(config-if)# dialer aaa suffix @samp password password12

Device(config-if)# exit

1.    enable


2.    debug radius


3.    show radius statistics


4.    show aaa servers


5.    exit

Device> enable

Device# debug radius

Device# show radius statistics

Device# show aaa servers

Device# exit

The following example shows a basic L2TP configuration with corresponding comments on the L2TP network server (LNS):

! Enable AAA globally.
aaa new-model
! Enable AAA authentication for PPP and list the default method to use for PPP
! authentication.
aaa authentication ppp default local
! Define the username as “partner.”
username partner password 7 030C5E070A00781B
! Create virtual-template 1 and assign all values for virtual access interfaces.
interface Virtual-Template1
! Borrow the IP address from loopback interface.
 ip unnumbered loopback0
! Disable multicast fast switching.
 no ip mroute-cache
! Use CHAP to authenticate PPP.
 ppp authentication chap
! Enable VPDN.
vpdn enable
! Create vpdn-group number 1.
vpdn-group 1
! Accept all dialin l2tp tunnels from virtual-template 1 from remote peer DJ.
 accept dialin l2tp virtual-template 1 remote DJ
  protocol any
  virtual-template 1
 terminate-from hostname nas1
local name hgw1

The following example shows how to configure the LNS with a basic L2TP configuration using RADIUS tunneling attributes:

aaa new-model
aaa authentication login default none
aaa authentication login console none
aaa authentication ppp default local group radius
aaa authorization network default group radius if-authenticated
! 
username l2tp-svr-auth-id password 0 l2tp-tnl-pass
! 
vpdn enable
vpdn search-order domain
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname l2tp-cli-auth-id
local name l2tp-svr-auth-id
!
interface GigabitEthernet1/0/0
ip address 10.0.0.3 255.255.255.0
no ip route-cache
no ip mroute-cache
!
interface Virtual-Template1
ip unnumbered loopback0
ppp authentication pap
!
radius-server host 10.1.1.1 auth-port 1645 acct-port 1646
radius-server key <deleted>