|
|
The access service security paradigm presented in this chapter uses the authentication, authorization, and accounting (AAA) facility. Authentication requires dialin users to prove they are who they say they are. When you require authentication before users can access your network, you are preventing users from either accessing lines on the Access Server Shelves or connecting through the lines directly to network resources. You need to secure every access point.
Authorization prevents each user from gaining access to services and devices on the network that they do not need to or are not permitted to access. Accounting provides records of who is connected and how long they have been connected for billing and other recording purposes. This chapter does not describe how to configure accounting. For more information about configuring accounting, refer to the Security Configuration Guide in the Cisco IOS configuration guides and command references documentation.
This chapter describes how to configure security using a remote security database for TACACS+ and RADIUS.
This chapter includes the following sections:
In a traditional ISP environment, you need a centralized security database that provides username and password information to the AccessPath system or to the home gateway router. This centralized security database resides in a security server. (See the TACACS+ Server and RADIUS Server in Figure 7-1.)
An example of a remote security database server is the CiscoSecure product from Cisco Systems, Inc. CiscoSecure is a UNIX security daemon solution, with which the administrator creates a database that defines the network users and their privileges. CiscoSecure uses a central database that stores user and group profiles with authentication and authorization information.
The Access Server Shelf exchanges user authentication information with a TACACS+ or RADIUS database on the security server by transmitting encrypted TACACS+ or RADIUS packets across the network.
For specific information about the interaction between the security server and the Access Server Shelf, refer to the Security Configuration Guide.
A centralized security database also helps establish consistent remote access policies throughout a corporation.
Using the AAA facility, you can authenticate users with the security database. The basic process of configuring the Cisco IOS software for authentication requires the following tasks:
The first thing you secure is access to privileged EXEC (enable) mode. Enable mode provides access to configuration mode, which enables any type of configuration change to the Access Server Shelf. To secure Privileged EXEC mode, use one of the commands listed in Table 7-1:
For more information about the enable password and enable secret commands and their complete syntax, refer to the Security Command Reference.
To enter an encryption type with the enable secret command, follow this procedure:
Step 2 Exit from global configuration mode and enter the command show running-config to view the encrypted version of the password. The following example illustrates these first two steps:
Step 3 At this point, select and copy the encrypted password following enable secret 5 in the configuration output ($1$h7dd$VTNs4.BAfQMUU0Lrvw6570).
Step 4 Enter global configuration mode and enter the enable secret command, followed by the encryption type (5 is the only valid encryption type for enable secret), then paste in the encrypted version of the password, as shown in the following example:
Step 5 Exit from global configuration mode and copy the running configuration to NVRAM.
You can also specify additional protection for privileged EXEC mode, including the following:
For more information about these security tools, refer to the Security Configuration Guide in the Cisco IOS configuration guides and command references documentation.
This section describes the Cisco IOS software commands that enable the AccessPath system to communicate with a security server. This process is similar for communicating with TACACS+ and RADIUS servers, and the following sections describe the process.
You must configure the security server before performing the tasks described in this chapter. The section "Security Examples" at the end of this chapter shows some typical TACACS+ and RADIUS server entries corresponding to the Access Server Shelf security configurations.
To enable communication between the TACACS+ security (database) server and the Access Server Shelf, issue the commands listed in Table 7-2 in global configuration mode.
For example, to enable the remote TACACS+ server to communicate with the Access Server Shelf, enter the commands as follows:
The host name of the TACACS+ server in the previous example is test. The key (abra2cad) in the previous example is the encryption key shared between the TACACS+ server and the Access Server Shelf.
For more information about TACACS+ commands, refer to the Security Command Reference, which is part of the Cisco IOS configuration guides and command references documentation.
To enable communication between the RADIUS security (database) server and the Access Server Shelf, issue the commands listed in Table 7-3 in global configuration mode.
For example, to enable the remote RADIUS server to communicate with the Access Server Shelf, enter the commands as follows:
The host name of the RADIUS server in the previous example is test. The key (abra2cad) in the previous example is the encryption key shared between the RADIUS server and the Access Server Shelf.
You can use any of the following optional commands to interact with the RADIUS server host:
This command specifies the number of times that the router transmits each RADIUS request to the server before the router gives up.
This command specifies the number of seconds that an Access Server Shelf waits for a reply to a RADIUS request before the Access Server Shelf retransmits the request. The default is 5 seconds. If the RADIUS server's response is slow (because of support for a large number of users or large network latency), increase the timeout value.
For more information about these commands, refer to the Security Command Reference, which is part of the Cisco IOS configuration guides and command references documentation.
On most TACACS+ security servers, there are three ways to authenticate a user for login:
The following is the configuration for global authentication:
To assign different passwords for CHAP, and a normal login, you must enter a string for each user that specifies the security protocols, whether the password is cleartext, and if it authentication is performed via a DES card. The following example shows a user carol, who has authentication configured for ARAP, CHAP, and login. Her ARAP and CHAP passwords, "arap password" and "chap password," are shown in clear text. Her login password has been encrypted.
The default authentication is to deny authentication. You can change this at the top level of the configuration file to have the default use the /etc/passwd file, by issuing the following command:
On the Access Server Shelf, you configure authentication on all lines including the VTY and Console lines by entering the following commands, beginning in privileged EXEC mode:
To use the AAA security facility in the Cisco IOS software, you must issue the aaa new-model command from global configuration mode.
When you issue the aaa new-model command, all lines on the Access Server Shelf receive the implicit login authentication default method list, and all interfaces with PPP enabled have an implicit ppp authentication pap default method list applied. In addition, the aaa new-model command applies implicit aaa authentication ppp default local and aaa authentication login default local commands.
Note Cisco recommends that you use CHAP authentication with PPP, rather than PAP. CHAP passwords are encrypted when they cross the network, whereas PAP passwords are cleartext when they cross the network. The Cisco IOS software selects PAP as the default, so you must manually select CHAP. The process for specifying CHAP is described in the "Applying Authentication Method Lists" section.
For example, enter the following commands to enable AAA in the Cisco IOS software:
After you enable AAA globally on the Access Server Shelf, you need to define authentication method lists, which you then apply to lines and interfaces. These authentication method lists are security profiles that indicate the protocol (ARAP or PPP) or login and authentication method (TACACS+, RADIUS, or local authentication).
To define an authentication method list, perform the following steps, which are described in this section:
1. Issue the aaa authentication command.
2. Specify protocol (ARAP or PPP) or login authentication.
3. Identify a list name or default. A list name is any alphanumeric string you choose. You assign different authentication methods to different named lists.
4. Specify the authentication method. You can specify multiple methods, such as tacacs+, followed by local in case a TACACS+ server is not available on the network.
5. Populate the local username database if you specified local as the authentication method (or one of the authentication methods). To use a local username database, you must issue the username global configuration command. Refer to the section "Populate the Local Username Database if Necessary."
After you define these authentication method lists, you apply them to one of the following:
The section "Applying Authentication Method Lists" describes how to apply these lists.
To define an authentication method list, start by issuing the aaa authentication global configuration command, as shown in the following example:
After you issue aaa authentication, you must specify one of the following dialin protocols as applicable for your network:
You can specify only one dialin protocol per authentication method list. However, you can create multiple authentication method lists with each of these options. You must give each list a different name, as described in the next section "Identify a List Name."
If you specify the ppp option, the default authentication protocol for PPP is PAP. For greater security, specify CHAP. The full interface command is ppp authentication chap.
A list name identifies each authentication list. You can choose either to use the keyword default, or choose any other name that describes the authentication list. For example, you might call it isdn-radius if you intend to apply it to interfaces configured for ISDN and RADIUS authentication. The list name can be any alphanumeric string. We recommend that you use default as the list name for all lines and interfaces internal to the AccessPath system, and different names for all lines and interfaces where dialin users will be authenticated.
You can create different authentication method lists and apply them to lines and interfaces selectively. You can even create a named authentication method list that you do not apply to a line or interface, but which you intend to apply at some later point, such as when you deploy a new login method for users.
After you define a list name, you must identify additional security attributes (such as local authentication versus TACACS+ or RADIUS).
In the following example, the default authentication method list for PPP dialin clients uses the local security database.
In the following example, the PPP authentication method list name is radius.
In the following example, the login authentication method list name is local.
After you identify a list name, you must specify an authentication method. An authentication method identifies how users are authenticated. For example, will users be authenticated by a local security database resident on the Access Server Shelf (local method)? Will they be authenticated by a remote security database, such as by a TACACS+ or RADIUS daemon? Will guest access to an AppleTalk network be permitted?
Authentication methods are defined with optional keywords in the aaa authentication command. The available authentication methods for PPP are described in Table 7-4.
Note If you are not sure whether you should use TACACS+ or RADIUS, here are some comparisons: TACACS+ encrypts the entire payload of packets passed across the network, whereas RADIUS only encrypts the password when it crosses the network. TACACS+ can query the security server multiple times, whereas a RADIUS server gives one response only and is therefore not as flexible regarding per-user authentication and authorization attempts.
You can specify multiple authentication methods for each authentication list. The following example authentication method list for PPP first queries a TACACS+ server, then a RADIUS server, then the local security database. Multiple authentication methods can be useful if a single security server type does not respond:
If you specify more than one authentication method and the first method (TACACS+ in the previous example) is not available, the Cisco IOS software attempts to authenticate using the next method (such as RADIUS). If in the previous example the RADIUS server has no information about the user, or if no RADIUS server can be found, the user is authenticated using the local username database that was populated with the username command.
However, if authentication fails using the first method listed, the Cisco IOS software does not permit access. It does not attempt to authenticate using the subsequent security methods if the user entered the incorrect password.
If you specify local as the security method, you must specify username profiles for each user who might log in. An example of specifying local authentication is as follows:
This command specifies that any time a user attempts to log in to a line on an Access Server Shelf, the Cisco IOS software checks the username database. To create a local username database, define username profiles using the username global configuration command.
The following example shows how to use the username command for a user myname with password mypassword:
The show running-config command shows the encrypted version of the password, as follows:
Note The Cisco IOS software adds the encryption type of 7 automatically for passwords. If you were to manually enter the number 7 to represent an encryption type, you must follow the 7 with the encrypted version of the password. If you specify the number 7, then enter a cleartext password, the user will not have access to the line, interface, or the network they are trying to access, and you must reconfigure the user's authentication profile.
This section shows some examples of authentication lists.
The following example creates a local authentication list for users logging in to any line on the Access Server Shelf. It is identical to the implicit method list when the command aaa new-model is used.
The following example specifies login authentication using RADIUS (the RADIUS daemon is polled for authentication profiles):
The following example specifies login authentication using TACACS+ (the TACACS+ daemon is polled for authentication profiles):
The following example creates a TACACS+ authentication list for users connecting to interfaces (such as ISDN BRI or asynchronous interfaces) configured for dialin using PPP. The name of the list is marketing. This example specifies that a remote TACACS+ daemon be used as the security database. If this security database is not available, the Cisco IOS software then polls the RADIUS daemon. Users are not authenticated if they are already authenticated on a TTY line.
In this example, default can be substituted for marketing if the administrator wants this list to be the default list.
As described in the "Defining Authentication Method Lists" section, the aaa authentication global configuration command creates authentication method lists or profiles. You apply these authentication method lists to lines or interfaces by issuing the login authentication, or ppp authentication command, as described in Table 7-5.
| Interface and Line Command | Action | Port to which List is Applied | Corresponding Global Configuration Command |
|---|---|---|---|
| 1If you issued the ppp authentication command, you must specify either CHAP or PAP authentication. PAP is enabled by default, but Cisco recommends that you use CHAP because CHAP is more secure. For more information, refer to the Security Configuration Guide. |
You can create more than one authentication list or profile for login and protocol authentication and apply them to different lines or interfaces. The following examples show the line or interface authentication commands that correspond to the aaa authentication global configuration command.
The following example shows the default login authentication list applied to the console port and the default virtual terminal (VTY) lines on the Access Server Shelf:
In the following example, the login authentication list named other-office, which uses RADIUS authentication, is created. It is applied to all 55 lines on an Access Server Shelf, including the console (CTY) port, the 48 physical asynchronous (TTY) lines, the auxiliary (AUX) port, and 5 virtual terminal (VTY) lines:
The following sample output shows lines and their status on the Access Server Shelf:
The following example creates the PPP authentication list marketing, which uses TACACS+, then RADIUS authentication. The list marketing requires authentication only if the user has not already been authenticated on another line. It is then applied to asynchronous lines 1 through 48 on a Access Server Shelf and uses CHAP authentication, instead of the default of PAP:
You can configure the Access Server Shelves to restrict user access to the network so that users can only perform certain functions after successful authentication. As with authentication, authorization can be used with either a local or remote security database. This guide describes only remote security server authorization.
A typical configuration most likely uses the EXEC facility and network authorization. EXEC authorization restricts access to the EXEC, and network authorization restricts access to network services, including PPP and ARA.
Authorization must be configured on both the Access Server Shelves and the security daemon. The default authorization is different on the Access Server Shelves and the security server:
Note If authentication has not been set up for a user, per-user authorization attributes are not enabled for that user. That is, if you want a user to authorize himself before he has access to network resources, you must first require that the user authenticate himself. For example, if you want to specify the aaa authorization network tacacs+ (or radius) command, you must first specify the aaa authentication {ppp} default if-needed tacacs+ (or radius) command.
You typically have three methods for configuring default authorization on the security server:
(a). If the AV pair from the Access Server Shelf is mandatory, look for an exact match in the daemon's mandatory list. If found, add the AV pair to the output.
(b). If an exact match does not exist. look in the daemon's optional list for the first attribute match. If found, add the Access Server Shelf AV pair to the output.
(c). If no attribute match exists, deny the command if the default is to deny, or if the default is permit, add the Access Server Shelf AV pair to the output.
(d). If the AV pair from the Access Server Shelf is optional, look for an exact attribute, value match in the mandatory list. If found, add the daemon's AV pair to output.
(e). If not found, look for the first attribute match in the mandatory list. If found, add daemon's AV pair to output.
(f). If no mandatory match exists, look for an exact attribute, value pair match among the daemon's optional AV pairs. If found, add the daemon's matching AV pair to the output.
(g). If no exact match exists, locate the first attribute match among the daemon's optional AV pairs. If found add the daemon's matching AV pair to the output.
(h). If no match is found, delete the AV pair if default is deny, or if the default is permit, add the Access Server Shelf AV pair to the output.
(i). If there is no attribute match already in the output list after all AV pairs have been processed for each mandatory daemon AV pair, add the AV pair (add only one AV pair for each mandatory attribute).
To specify network authorization, which means that you are preventing unauthorized users from accessing network resources, issue the aaa authorization network command.
To restrict users from logging into the EXEC facility, issue the aaa authorization exec command. See the following example:
Note You can also require authorization before a user can issue specific commands by using the aaa authorization command. For more information, refer to the Security Configuration Guide, which is part of the Cisco IOS configuration guides and command references documentation.
Authorization methods are defined as optional keywords in the aaa authorization command. You can specify any of the authorization methods listed in Table 7-6 for both network and EXEC authorization.
When you configure authorization, you must ensure that the parameters established on the Access Server Shelf correspond with those set on the TACACS+ server.
The following example uses a TACACS+ server to authorize the use of network services, including PPP and ARA. If the TACACS+ server is not available or has no information about a user, no authorization is performed, and the user can use all network services:
The following example permits the user to run the EXEC process if the user is already authenticated. If the user is not already authenticated, the Cisco IOS software defers to a RADIUS server for authorization information.
The following example configures network authorization. If the TACACS+ server does not respond or has no information about the username being authorized, the RADIUS server is polled for authorization information for the user. If the RADIUS server does not respond, the user still can access all network resources without authorization requirements.
You use the aaa accounting command with the radius keyword to turn on RADIUS accounting for each Cisco IOS privilege level, and network services.
To use RADIUS accounting to send a start record accounting notice at the beginning of an EXEC process and a stop record at the end, perform the following task in global configuration mode:
This series of examples shows complete security configuration components of a configuration file on an Access Server Shelf. Each of these examples shows authentication and authorization.
This sample configuration uses AAA to configure default authentication using a local security database on the Access Server Shelf. All lines and interfaces have the default authentication lists applied. Users myname1, myname2, and myname3 have been assigned privilege level 7, which prevents them from issuing the ppp and slip commands, because these commands have been assigned to privilege level 8.
With this configuration, the sign-on dialog from a remote PC appears as follows:
The following example shows how to create and apply the following authentication lists:
The following example shows how to create the following authentication lists:
Posted: Mon Jan 20 21:15:39 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
