Configuring RADIUS Globally

The configuration of RADIUS is almost identical to the configuration of TACACS+. RADIUS can be configured on a global basis, which is generally used in environments that use one RADIUS server or in environments in which all RADIUS servers within the network are configured to use the same security values. To configure RADIUS on the network access server, you must perform the following steps (note Steps 4 through 6 are optional):

1.Use the aaa new−model global configuration command to enable AAA. This command establishes a new AAA configuration. The command must be configured if you plan to support the RADIUS protocol.

2.Use the following command to configure the IP address or hostname of the RADIUS server:

radius−server host <hostname|ip−address>

3.Use this command to define the secret encryption key that is shared between the network access server and the RADIUS server:

radius−server key <0 string|7 string|string>

4.Use the radius−server retransmit <retries> command to specify how many times the router transmits each RADIUS request to the server before giving up.

5.Use the radius−server timeout <second> command to specify how many seconds a router waits for a reply to a RADIUS request before retransmitting the request.

6.Use the radius−server deadtime <minutes> command to specify how many minutes should pass before a RADIUS server that is not responding to authentication requests is passed over by requests for RADIUS authentication.

The preceding steps include the basic configuration commands needed to enable RADIUS globally on the network access server. Continuing with the example in Figure 2.8, the network access server named Seminole should now be configured to provide RADIUS services for user James. The access server Seminole is configured to communicate with the Cisco Secure ACS server at IP address 192.168.10.4.

The following configuration commands are needed to configure the router based on the requirements:

Seminole#config t

Enter configuration commands, one per line. End with CNTL/Z.

Seminole(config)#aaa new−model

Seminole(config)#radius−server host 192.168.10.4

Seminole(config)#radius−server key 1Cisco9

Notice the similarities between the global configuration of TACACS+ and the global configuration of RADIUS. In the preceding configuration, the key 1Cisco9 is the encryption key that is shared between router Seminole and the Cisco Secure server at IP address 192.168.10.4. Issuing the show running−config command allows you to see the results of the preceding configuration:

Seminole#show running−config

!

hostname Seminole

!

aaa new−model

radius−server host 192.168.10.4 radius−server key 1Cisco9

61

!

By issuing the show running−config command, you can review the configuration changes that were made to the local device; however, a few more commands are needed to verify that the network access server and the RADIUS server are communicating properly. After you verify that the configuration changes are correct, the next command you should issue is the debug radius command. The output of this command verifies that the network access server and the RADIUS server are communicating properly. The output of the debug radius command verifies that the network access server and the RADIUS server are communicating properly; the following lines show that the network access server Seminole in Figure 2.8 is communicating with the RADIUS server:

Seminole#debug radius

:Radius: IPC send 0.0.0.0/1645, Access−Request, id 0xB, len 52

:Attribute 4 6 AB187D5B

:Attribute 5 6 0000000B

:Attribute 2 6 0212D3C2

:Attribute 2 18 D21512AC

:Radius: Received from 192.168.10.4:1645, Access−Accept, : id 0xB, len 24

The output of the debug radius command displays the attribute values that are carried in the RADIUS Access−Request packet and the length of the packet. The last line in the output displays the packet that is received from the RADIUS server and the Access−Accept value being returned to the network access server. If, however, the RADIUS server and the network access server could not communicate properly, the output from the debug radius would resemble this output:

:Radius: IPC Send 0.0.0.0:1645, Access−Request, id 0xA, len 57

:Attribute 4 6 AC150E5A

:Attribute 5 6 0000000A

:Attribute 1 7 62696C6C

:Attribute 2 18 49C28F6C

:Radius: Received from 192.168.10.4:1645, Access−Reject, : id 0xA, len 20

:Radius: Reply for 4 fails decrypt

Configuring RADIUS Individually

As with TACACS+, RADIUS allows a finer granularity of control in specifying features on a per−security−server basis. This method of RADIUS configuration is generally used in environments that utilize multiple RADIUS servers and each server is configured to use separate values. Follow these steps to enable this method of RADIUS configuration:

1.Use the aaa new−model global configuration command to enable AAA. This command establishes a new AAA configuration. The command must be configured if you plan to support the RADIUS protocol.

2.Use the following command to specify the IP address of one or more RADIUS servers:

radius−server host {hostname|ip−address} <auth−port –

62

port−number> <acct−port port−number> <timeout seconds> − <retransmit retries> <key string> <alias –

{hostname|ip address}>

The network access server searches for the hosts in the order specified; this feature allows you to set up a list of preferred servers.

The IP address parameter above specifies the IP address or hostname of the remote RADIUS server host and assigns authentication and accounting destination port numbers. The auth−port port−number option allows the administrator to configure on this RADIUS server a specific UDP port to be used solely for authentication. This port number defaults to 1645 if it is not explicitly configured. The acct−port port−number option allows the administrator to configure on this RADIUS server a specific UDP port to be used solely for accounting. This port number defaults to 1646 if it is not explicitly configured. Use the alias keyword to configure up to eight multiple IP addresses for use when referring to RADIUS servers. Set the timeout, retransmit, and encryption key values to use with the specific RADIUS host.

The Cisco IOS allows you to configure many values at a global level; these values affect all other related values configured on the router. The method detailed in the preceding steps allows you to enhance security on your network by uniquely configuring individual RADIUS connections for multiple servers and applying separate values for each server. Use the preceding configuration steps in instances in which your network has many independent RADIUS servers and each server has different values configured.

The following example configures two servers with separate values (refer back to Figure 2.9); the servers should now be configured to support RADIUS as opposed to TACACS+:

#config t #aaa new−model

#radius−server host 192.168.10.4 timeout 20 key 1Cisco9 #radius−server host 192.168.10.5 timeout 45 key 2Systems8

The server with the IP address 192.168.10.4 is configured with a timeout value of 20 and a key value of 1Cisco9. However, the server with the IP address 192.168.10.5 is configured with different values. It is configured with a higher timeout value of 45 and a separate key value of 2Systems8. Issuing the show running−config command allows you to view the results of the preceding configuration:

Seminole#show running−config

!

hostname Seminole

!

aaa new−model

radius−server host 192.168.10.4 auth−port 1645 acct−port 1646 – timeout 20 key 1Cisco9

!

radius−server host 192.168.10.5 auth−port 1645 acct−port 1646 – timeout 45 key 2Systems8

!

63

After verifying that the configuration changes are correct, you should issue the debug radius command. The output of this command verifies that the network access server and the TACACS+ server are communicating properly:

Note Use debug commands with great care. In general, it is recommended that these commands only be used under the direction of a technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when networks are experiencing high load conditions.

Seminole#debug radius

:Radius: IPC send 0.0.0.0/1645, Access−Request, id 0xB, len 52

:Attribute 4 6 AB187D5B

:Attribute 5 6 0000000B

:Attribute 2 6 0212D3C2

:Attribute 2 18 D21512AC

:Radius: Received from 192.168.10.4:1645, Access−Accept, : id 0xB, len 24

!

:Radius: IPC Send 0.0.0.0:1645, Access−Request, id 0xB, len 56

:Attribute 4 6 AB246E4C

:Attribute 5 6 0000000A

:Attribute 1 6 62696C6C

:Attribute 2 18 C22631BD

:Radius: Received from 192.168.10.5:1645, Access−Accept, : id 0xB, len 26

!

Configuring Authentication

After you enable TACACS+ or RADIUS globally on the network device, you must define the authentication methods used to verify users before they are allowed access to the network and network services. To configure AAA authentication, first define a named list of authentication methods and then apply that list to the correct interfaces. The method list defines the types of authentication to be performed and the sequence in which they will be performed; it must be applied to a specific interface before any of the defined authentication methods will be performed. The default method list, however, is an exception; it is automatically applied to all interfaces except those that have a named method list explicitly defined on them. A defined method list overrides the default method list.

A method list is a sequential list that describes the authentication methods to be used to authenticate a user. Cisco IOS software uses the first configured method listed to authenticate users. If that method fails to respond or returns an error, it selects the next authentication method listed in the method list. This process continues until there is successful communication with a listed authentication method or until all methods defined in the method list are exhausted.

Note The Cisco IOS software attempts authentication with the next configured authentication method only when there is no response from the preceding method or the method returns an error.

To configure AAA authentication, perform the following steps:

1.Enable AAA by using the aaa new−model global configuration command and configuring any security protocol parameters, such as the key value. This step was outlined earlier in the sections on configuring TACACS+ and RADIUS.

2.Define the method lists for authentication by using the following command:

64

aaa authentication <arap|login|enable|ppp|nasi> <default| − list−name> group <method1> <method2> <method3> − <method4>

3. Apply the method lists to a particular interface or line, using the following command:

login authentication {default|list name}

The aaa authentication command authenticates arap, login, enable, ppp, and nasi connections. As an example of how to configure these connections, router Seminole in Figure 2.8 will be configured to authenticate user James for Telnet access via the security server at IP address 192.168.10.4. All other lines will use the default list. Listing 2.2 displays the configuration commands needed to enable Seminole to authenticate James for Telnet access via the TACACS+ server.

Listing 2.2: Router Seminole authentication configuration.

#aaa new−model

#tacacs−server host 192.168.10.4 #tacacs−server key 1Cisco9

#aaa authentication login TELNET group tacacs − local enable none

#aaa authentication login ADMIN none #line con 0

#login authentication ADMIN #line vty 0 4

#login authentication TELNET #end

The configuration in Listing 2.2 creates a list named TELNET and defines four methods that should be used to authenticate the virtual terminal lines that are configured to use the list. The console port will use the method list named ADMIN, which specifies that no authentication is to take place. Listing 2.3 is part of the output from the command debug aaa authentication, which is used to verify whether the login attempt from user James was successful. This output also indicates that TACACS+ is the authentication method used by the router.

Listing 2.3: Successful login authentication output.

Seminole#debug aaa authen

AAA Authentication debugging is on

Seminole#

:AAA: parse name=tty2 idb type=−1 tty=−1

:AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 –

:port=2 channel=0

:AAA/MEMORY: create_user (0x62527B28) user='' ruser='' – port='tty2' rem_addr='192.168.11.45' authen_type=ASCII – service=LOGIN priv=1

:AAA/AUTHEN/START (3898654566): port='tty2' list='TELNET' – action=LOGINservice=LOGIN: AAA/AUTHEN/START : found list – TELNET

:AAA/AUTHEN/START (3898654566): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/START packet ver=192 id=3898654566

:TAC+: ver=192 id=3898654566 received AUTHEN status = GETUSER

:AAA/AUTHEN (3898654566): status = GETUSER

:AAA/AUTHEN/CONT (3898654566): continue_login (user='(undef)')

:AAA/AUTHEN (3898654566): status = GETUSER

:AAA/AUTHEN (3898654566): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/CONT packet id=3898654566

65

:TAC+: ver=192 id=3898654566 received AUTHEN status = GETPASS

:AAA/AUTHEN (3898654566): status = GETPASS

:AAA/AUTHEN/CONT (3898654566): continue_login (user='James')

:AAA/AUTHEN (3898654566): status = GETPASS

:AAA/AUTHEN (3898654566): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/CONT packet id=3898654566

:TAC+: ver=192 id=3898654566 received AUTHEN status = PASS

:AAA/AUTHEN (3898654566): status = PASS

:TAC+: (4047621580): received author response status = PASS_ADD

Notice that the first few lines of the output determine that a connection has been requested on port tty2 and the authentication list named TELNET is defined on the line for LOGIN services. The router then begins to read through its configured lists to find a match for TELNET. Upon finding the list named TELNET, the router determines that the authentication method that should be used to authenticate the user is method TACACS+. The router then receives a request from the security server to retrieve the username from the user requesting access with the GETUSER request. The process continues with the security server, and then the router is asked to supply a password for the user. After verifying the supplied credentials, the security server responds with a PASS status packet and the user has been authenticated.

If, for instance, user James fails the authentication process, the response that is generated by the router would resemble the output in Listing 2.4

Listing 2.4: Failed login authentication output.

:AAA: parse name=tty2 idb type=−1 tty=−1

:AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 – port=2 channel=0

:AAA/MEMORY: create_user (0x6257E6A8) user='' ruser='' – port='tty2'

rem_addr='192.168.11.45' authen_type=ASCII service=LOGIN – priv=1

:AAA/AUTHEN/START (2841923342): port='tty2' list='TELNET' – action=LOGINservice=LOGIN: AAA/AUTHEN/START : found list – TELNET

:AAA/AUTHEN/START (2841923342): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/START packet ver=192 id=2841923342

:TAC+: ver=192 id=2841923342 received AUTHEN status = GETUSER

:AAA/AUTHEN (2841923342): status = GETUSER

:AAA/AUTHEN/CONT (2841923342): continue_login (user='(undef)')

:AAA/AUTHEN (2841923342): status = GETUSER

:AAA/AUTHEN (2841923342): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/CONT packet id=2841923342

:TAC+: ver=192 id=2841923342 received AUTHEN status = GETPASS

:AAA/AUTHEN (2841923342): status = GETPASS

:AAA/AUTHEN/CONT (2841923342): continue_login (user='James')

:AAA/AUTHEN (2841923342): status = GETPASS

:AAA/AUTHEN (2841923342): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/CONT packet id=2841923342

:TAC+: ver=192 id=2841923342 received AUTHEN status = FAIL

:AAA/AUTHEN (2841923342): status = FAIL

:AAA/MEMORY: free_user (0x6257E6A8) user='James' ruser='' – port='tty2' rem_addr='192.168.11.45' authen_type=ASCII – service=LOGIN priv=1

As explained in Chapter 1, Cisco routers have different modes of operation. These modes are generally protected with passwords so that certain users cannot just walk up and gain access to the

66

router. The enable password and enable secret password are frequently configured to secure privileged mode access into a Cisco router. Although it's a good start, there are some limitations to using this method alone. This method of security is burdensome to administer in enterprises that contain hundreds of routers. For instance, if the password needs to be changed for any reason, someone either has to physically go to each router and plug into it to change the password or has to telnet to each router. The point is that this could become an administrative nightmare. Another drawback to using this method is that the password must be known by all users who need access into the router. Fortunately, Cisco routers can be configured to authenticate a user via a security server for privileged mode access. This allows administrators to change the password in one place, giving them centralized control. In environments that use an external Windows NT/2000 database for authentication, each user has control of his or her own enable password.

Continuing with the authentication example, the router Seminole should be configured to authenticate users via the security server for privileged mode access. This can be accomplished using the following configuration commands:

#config t

#aaa authentication enable default group tacacs+ enable none #end

#

The configuration commands in Listing 2.4 configure the router to authenticate privileged mode access using the TACACS+ method; if the security server returns an error, then authenticate the user using the configured enable password. After initiating a Telnet session to the router, James now must enter enable mode. Listing 2.5 shows the output when James accesses privileged mode is shown in.

Listing 2.5: Authentication debug output.

Seminole>en

Password:

Seminole#

:AAA/MEMORY: dup_user (0x6255EA00) user='James' ruser='' – port='tty2' rem_addr='192.168.11.45' authen_type=ASCII – service=ENABLE priv=15 source='AAA dup enable'

:AAA/AUTHEN/START (757557072): port='tty2' list='' − action=LOGIN service=ENABLE

:AAA/AUTHEN/START (757557072): using "default" list

:AAA/AUTHEN/START (757557072): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/START packet ver=192 id=757557072

:TAC+: ver=192 id=757557072 received AUTHEN status = GETPASS

:AAA/AUTHEN (757557072): status = GETPASS

:AAA/AUTHEN/CONT (757557072): continue_login (user='James')

:AAA/AUTHEN (757557072): status = GETPASS

:AAA/AUTHEN (757557072): Method=tacacs+ (tacacs+)

:TAC+: send AUTHEN/CONT packet id=757557072

:TAC+: ver=192 id=757557072 received AUTHEN status = PASS

:AAA/AUTHEN (757557072): status = PASS

:AAA/MEMORY: free_user (0x6255EA00) user='James' ruser='' – port='tty2' rem_addr='10.191.150.45' authen_type=ASCII – service=ENABLE priv=15

In the first line, the router determines that the user logging in is a duplicate user who is requesting enable mode access. The router knows that the user is a duplicate user because after the user is

67

successfully authenticated, the router caches the supplied username credential. After receiving the GETPASS from the security server, the router prompts James to enter his password and passes the value back to the security server. The security server then sends the Pass or Fail status to the router.

Prior to Cisco IOS 12.0, there were instances when an administrator could accidentally lock himself out of his network access server with an incorrect AAA configuration. In order to remedy this problem, Cisco developed the aaa authentication local−override command. This command proved to be very useful when you wanted to configure an override to the normal authentication method list processing the network access server performed for certain personnel, such as system administrators. With the override command configured, the user was always prompted for his username. The system then checked to see if the username that was entered corresponded to a local account configured with the following command:

username name privilege level password password

If the username does not correspond to one in the local database, login proceeds with the methods configured with other aaa commands (such as aaa authentication login). An example of configuring the local−override feature is shown here:

Seminole# config t

Enter configuration commands, one per line. End with CNTL/Z.

Seminole(config)#aaa authentication local−override

Seminole(config)#end

Seminole#

The result of configuring the local−override command can be viewed by using the show running−config command:

Seminole#show running−config Building configuration...

!

Current configuration:

!

version 11.2 aaa new−model

aaa authentication local−override

!

However, with newer 12.0+ code, the aaa authentication local−over−ride is no longer a configuration option. This can be verified using the following method.

68

password−prompt Text to use when prompting for a password. ppp Set authentication lists for ppp. username−prompt Text to use when prompting for a username.

With 12.0+ code, when access to the network access devices is critical at all times and administrators need the same functionality they get when they use the local−override command, you can configure a default method of access into the network access device. This can be accomplished using the following command:

#config t

#aaa authentication login default local group tacacs enable line Seminole#

This example provides the same features that the aaa authentication local−override command provided. For login authentication, the network access server will first check the default method that is configured to authenticate the remote user (in this case, it's the local database). Then, if the username is not found in the local database, the network access server will attempt to authenticate the user using the first method configured in the method list—in this case, TACACS+. If the TACACS+ server returns an error to the network access server, the network access server will then try the next method configured—in this case, the enable password—in an attempt to authenticate the user.

Configuring PAP and CHAP Authentication

The CHAP and PAP protocols are supported on synchronous and asynchronous serial interfaces. When using CHAP or PAP authentication, each router or access server uses a name to identify itself. This identification process prevents a router from placing another call to a router it's already connected to, and it also prevents unauthorized access. Access control using CHAP or PAP is available on all serial interfaces that use PPP encapsulation. To use the features of PAP and CHAP, perform the following steps:

1.Enable PPP encapsulation on an interface using the interface configuration mode encapsulation ppp command.

2.Enable CHAP or PAP authentication on the interface configured for PPP encapsulation by using the following command in interface configuration mode:

ppp authentication {chap|chap pap|pap chap|pap} [if−needed] [list−name|default] [callin]

3. Configure the appropriate usernames and passwords using this command:

username name <user−maxlinks link−number> password <secret>

The passwords are case sensitive and must be identical at both ends.

Figure 2.10 lists three users who need secure remote access to the corporate office. The users remotely connect to the corporate network and are authenticated via CHAP. The configuration of the network access server is shown in Listing 2.6.

69

Figure 2.10: Remote client PPP connection.

Listing 2.6: PPP network access server.

!

hostname Seminole

!

username james password letmein username admin password admin username john password cto

!

interface Ethernet0

ip address 192.168.10.1 255.255.255.0

!

interface Group−Async1 encapsulation ppp async mode interactive

peer default ip address pool remote−users ppp authentication pap

group−range 1 16

!

ip local pool remote−users 192.168.39.239 192.168.39.254

!

line 1 16 login local

autoselect during−login autoselect ppp

modem InOut transport input all

The configuration in Listing 2.6 defines three users with separate passwords. Interface group−assync1 is configured for PPP as the encapsulation protocol, and the method of authentication is PAP. The group−range command under interface group−async1 defines the lines that are part of the group−async1 interface. Notice that PAP was chosen as the authentication protocol; CHAP could have been specified instead using the ppp authentication chap command. In environments that support both PAP and CHAP, the access server attempts to authenticate a user with the first configured authentication method; if that method fails or if the client device does not support the first authentication method, the access server will attempt to use the next configured method. This is accomplished using the following command:

ppp authentication chap pap

70

However, the example in Listing 2.6 can sometimes become a burden because of the overhead of maintaining a local security database on the network access server. In environments in which there is the potential to have hundreds, maybe even thousands of remote clients connecting to the access server, the local security database method is not feasible because of scalability issues. Fortunately, in environments that use the services of a central security database, like the Cisco Secure ACS server, the authentication process can be offloaded to the Cisco Secure ACS server. As an example, the network access server in Figure 2.10 will be configured to authenticate the users via the AAA security server. Listing 2.7 details the configuration needed to enable authentication via the AAA security server.

Listing 2.7: Remote authentication using TACACS+.

!

hostname Seminole

!

aaa new−model

aaa authentication login default group tacacs+ enable local none aaa authentication login ADMIN none

aaa authentication ppp default if−needed group tacacs+ − local enable

!

username admin password admin

!

interface Ethernet0

ip address 192.168.10.1 255.255.255.0

!

interface Serial0:23 no ip address encapsulation ppp

!

interface Group−Async1 ip unnumbered Ethernet0 encapsulation ppp

ip tcp header−compression passive async mode interactive

peer default ip address pool IP ppp callback accept

ppp authentication chap group−range 1 16

!

ip local pool IP 192.168.10.239 192.168.10.254

!

tacacs−server host 192.168.10.4 single−connection timeout 10 – key 1Cisco9

!

line con 0

login authentication ADMIN line 1 16

modem InOut

autoselect during−login autoselect ppp

This configuration authenticates the remote clients via the TACACS+ server prior to authorizing and accounting the users.

71