Table Of Contents
Configuring Authorization
AAA Authorization Types
AAA Authorization Methods
AAA Authorization Prerequisites
AAA Authorization Configuration Task List
Configure Authorization
TACACS+ Authorization
If-Authenticated Authorization
None Authorization
Local Authorization
RADIUS Authorization
Kerberos Authorization
Disable Authorization for Global Configuration Commands
Authorization for Reverse Telnet
Authorization Attribute-Value Pairs
Authorization Configuration Examples
TACACS+ Authorization Example
RADIUS Authorization Example
Kerberos Instance Mapping Examples
Reverse Telnet Authorization Examples
Configuring Authorization
AAA authorization enables you to limit the services available to a user. When AAA authorization is enabled, the network access server 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. Once this is done, the user will be granted access to a requested service only if the information in the user profile allows it.
This chapter describes the following topics and tasks:
•
AAA Authorization Types
•
AAA Authorization Methods
•
AAA Authorization Prerequisites
•
AAA Authorization Configuration Task List
•
Configure Authorization
•
Disable Authorization for Global Configuration Commands
•
Authorization for Reverse Telnet
•
Authorization Attribute-Value Pairs
•
Authorization Configuration Examples
For a complete description of the authorization commands used in this chapter, refer to the "Authorization Commands" chapter in the Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
AAA Authorization Types
Cisco IOS software supports three different types of authorization:
•
EXEC—Applies to the attributes associated with a user EXEC terminal session.
•
Command—Applies to the EXEC mode commands a user issues. Command authorization attempts authorization for all EXEC mode commands, including global configuration commands, associated with a specific privilege level.
•
Network—Applies to network connection. This can include a PPP, SLIP, or ARAP connection.
AAA Authorization Methods
AAA supports five different methods of authorization:
•
TACACS+—The network access server exchanges authorization information with the TACACS+ security daemon. TACACS+ authorization defines specific rights for users by associating attribute-value pairs, which are stored in a database on the TACACS+ security server, with the appropriate user.
•
If-Authenticated—The user is allowed to access the requested function provided the user has been authenticated successfully.
•
Local—The router or access server consults its local database, as defined by the username command, to authorize specific rights for users. Only a limited set of functions can be controlled via the local database.
•
RADIUS—The network access server requests authorization information from the RADIUS security server. RADIUS authorization defines specific rights for users by associating attributes, which are stored in a database on the RADIUS server, with the appropriate user.
•
Kerberos Instance Map—The network access server uses the instance defined by the kerberos instance map command for authorization.
Note
Authorization, unlike authentication, cannot be applied selectively per interface.
AAA Authorization Prerequisites
Before configuring authorization, you must first perform the following tasks:
•
Enable AAA on your network access server. For more information about enabling AAA on your Cisco router or access server, refer to the "AAA Overview" chapter.
•
Configure AAA authentication. Authorization generally takes place after authentication and relies on authentication to work properly. For more information about AAA authentication, refer to the "Configuring Authentication" chapter.
•
Define the characteristics of your RADIUS or TACACS+ security server, if you are using RADIUS or TACACS+ authorization. For more information about configuring your Cisco network access server to communicate with your RADIUS security server, refer to the "Configuring RADIUS" chapter. For more information about configuring your Cisco network access server to communicate with your TACACS+ security server, refer to the "Configuring TACACS+" chapter.
•
Define the rights associated with specific users by using the username command, if you are using local authorization. For more information about the username command, refer to the Security Command Reference.
•
Create the administrative instances of users in the Kerberos key distribution center by using the kerberos instance map command, if you are using Kerberos. For more information about Kerberos, refer to the "Configuring Kerberos" chapter.
AAA Authorization Configuration Task List
This chapter describes the following tasks:
•
Configure Authorization
•
Disable Authorization for Global Configuration Commands
For authorization configuration examples using the commands in this chapter, refer to the "TACACS+ Configuration Examples" section located at the end of the this chapter.
Configure Authorization
The aaa authorization command allows you to set parameters that restrict a user's network access. To enable AAA authorization, perform the following task in global configuration mode:
Task
|
Command
|
Set parameters that restrict a user's network access.
|
aaa authorization {network | exec | command level} {tacacs+ | if-authenticated | none | local | radius | krb5-instance}
|
Note
Authorization is bypassed for authenticated users who log in using the console line, even if authorization has been configured.
To enable authorization for all network-related service requests (including SLIP, PPP, PPP NCPs, and ARA protocols), use the network keyword. To enable authorization to determine if a user is allowed to run an EXEC shell, use the exec keyword.
To enable authorization for specific, individual EXEC commands associated with a specific privilege level, use the command keyword. This allows you to authorize all commands associated with a specified command level from 0 to 15.
TACACS+ Authorization
To have the network access server request authorization information via a TACACS+ security server, use the aaa authorization command with the tacacs+ method keyword. For more specific information about configuring authorization using a TACACS+ security server, refer to the "Configuring TACACS" chapter. For an example of how to enable a TACACS+ server to authorize the use of network services, including PPP and ARA, see the "TACACS+ Authorization Example" section at the end of this chapter.
If-Authenticated Authorization
To allow users to have access to the functions they request as long as they have been authenticated, use the aaa authorization command with the if-authenticated method keyword. If you select this method, all requested functions are automatically granted to authenticated users.
None Authorization
To perform no authorization for the actions associated with a particular type of authentication, use the aaa authorization command with the none method keyword. If you select this method, authorization is disabled for all actions.
Local Authorization
To select local authorization, which means that the router or access server consult its local user database to determine the functions a user is permitted, use the aaa authorization command with the local method keyword. The functions associated with local authorization are defined by using the username global configuration command. For a list of permitted functions, refer to the "Configuring Authentication" chapter.
RADIUS Authorization
To have the network access server request authorization via a RADIUS security server, use the aaa authorization command with the radius method keyword. For more specific information about configuring authorization using a RADIUS security server, refer to the "Configuring RADIUS" chapter. For an example of how to enable a RADIUS server to authorize services, see the "RADIUS Authorization Example" section at the end of this chapter.
Kerberos Authorization
To run authorization to determine if a user is allowed to run an EXEC shell at a specific privilege level based on a mapped Kerberos instance, use the krb5-instance method keyword. For more information, refer to the "Enable Kerberos Instance Mapping" section of the "Configuring Kerberos" chapter. For an example of how to enable Kerberos instance mapping, see the "Kerberos Instance Mapping Examples" section at the end of this chapter.
Disable Authorization for Global Configuration Commands
The aaa authorization command with the keyword command attempts authorization for all EXEC mode commands, including global configuration commands, associated with a specific privilege level. Because there are configuration commands that are identical to some EXEC-level commands, there can be some confusion in the authorization process. Using no aaa authorization config-commands stops the network access server not from attempting configuration command authorization. To disable AAA authorization for all global configuration commands, perform the following task in global configuration mode:
Task
|
Command
|
Disable authorization for all global configuration commands.
|
no aaa authorization config-command
|
Authorization for Reverse Telnet
Telnet is a standard terminal emulation protocol used for remote terminal connection. Normally, you log in to a network access server (NAS) (typically through a dialup connection) and then use Telnet to access other network devices from that NAS. There are times, however, when it is necessary to establish a reverse Telnet session. In reverse Telnet sessions, the Telnet connection is established in the opposite direction—from inside a network to a NAS on the network periphery to gain access to modems or other devices connected to that NAS. Reverse Telnet is used to provide users with dialout capability by allowing them to Telnet to modem ports attached to a NAS.
It is important to control access to ports accessible through reverse Telnet. Failure to do so could, for example, allow unauthorized users free access to modems where they can trap and divert incoming calls or make outgoing calls to unauthorized destinations.
Authentication during reverse Telnet is performed through the standard AAA login procedure for Telnet. Typically the user has to provide a username and password to establish either a Telnet or reverse Telnet session. Reverse Telnet authorization provides an additional (optional) level of security by requiring authorization in addition to authentication. When enabled, reverse Telnet authorization can use RADIUS or TACACS+ to authorize whether or not this user is allowed reverse Telnet access to specific asynchronous ports, after the user successfully authenticates through the standard Telnet login procedure.
Reverse Telnet authorization offers the following benefits:
•
An additional level of protection by ensuring that users engaged in reverse Telnet activities are indeed authorized to access a specific asynchronous port using reverse Telnet.
•
An alternative method (other than access lists) to manage reverse Telnet authorization.
To configure a NAS to request authorization information from a TACACS+ or RADIUS server before allowing a user to establish a reverse Telnet session, perform the following task in global configuration mode:
Task
|
Command
|
Configure the NAS to request authorization information before allowing a user to establish a reverse Telnet session.
|
aaa authorization reverse-access {radius | tacacs+}
|
This feature enables the NAS to request reverse Telnet authorization information from the security server, whether RADIUS or TACACS+. You must configure the specific reverse Telnet privileges for the user on the security server itself.
Authorization Attribute-Value Pairs
RADIUS and TACACS+ authorization both define specific rights for users by processing attributes, which are stored in a database on the security server. For both RADIUS and TACACS+, attributes are defined on the security server, associated with the user, and sent to the network access server where they are applied to the user's connection.
For a list of supported RADIUS attributes, refer to the "RADIUS Attributes" appendix. For a list of supported TACACS+ AV pairs, refer to the "TACACS+ Attribute-Value Pairs" appendix.
Authorization Configuration Examples
This section contains the following configuration examples:
•
TACACS+ Authorization Examples
•
RADIUS Authorization Example
•
Kerberos Instance Mapping Examples
•
Reverse Telnet Authorization Examples
TACACS+ Authorization Example
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 an error occurs during the authorization process, the fallback method (none) is to grant all authorization requests:
aaa authorization network tacacs+ none
The following example allows network authorization using TACACS+:
aaa authorization network tacacs+
The following example provides the same authorization, but also creates address pools called mci and att:
aaa authorization network tacacs+
ip local-pool mci 172.16.0.1 172.16.0.255
ip local-pool att 172.17.0.1 172.17.0.255
These address pools can then be selected by the TACACS daemon. A sample configuration of the daemon follows:
login = cleartext "some password"
service = ppp protocol = ip {
login = cleartext "some other password"
service = ppp protocol = ip {
RADIUS Authorization Example
The following example shows how to configure the router to authorize using RADIUS:
aaa authorization exec radius if-authenticated
aaa authorization network radius
The lines in this sample RADIUS authorization configuration are defined as follows:
•
The aaa authorization exec radius if-authenticated command configures the network access server to contact the RADIUS server to determine if users are permitted to start an EXEC shell when they login. If an error occurs when the network access server contacts the RADIUS server, the fallback method is to permit the CLI to start, provided the user has been properly authenticated.
The RADIUS information returned may be used to specify an autocommand or a connection access list be applied to this connection.
•
The aaa authorization network radius command configures network authorization via RADIUS. This can be used to govern address assignment, the application of access lists, and various other per-user quantities.
Note
Since no fallback method is specified in this example, authorization will fail if, for any reason, there is no response from the RADIUS server.
Kerberos Instance Mapping Examples
The following global configuration example maps the Kerberos instance, admin, to enable mode:
kerberos instance map admin 15
The following example configures the router to check users' Kerberos instances and set appropriate privilege levels:
aaa authorization exec krb5-instance
For more information about configuring Kerberos, refer to the "Configuring Kerberos" chapter.
Reverse Telnet Authorization Examples
The following example causes the NAS to request authorization information from a TACACS+ security server before allowing a user to establish a reverse Telnet session:
aaa authentication login default tacacs+
aaa authorization reverse-access tacacs+
tacacs-server host 172.31.255.0
The lines in this sample TACACS+ reverse Telnet authorization configuration are defined as follows:
•
The aaa new-model command enables AAA.
•
The aaa authentication login default tacacs+ command specifies TACACS+ as the default method for user authentication during login.
•
The aaa authorization reverse-access tacacs+ specifies TACACS+ as the method for user authorization when trying to establish a reverse Telnet session.
•
The tacacs-server host command identifies the TACACS+ server.
•
The tacacs-server timeout command sets the interval of time that the NAS waits for the TACACS+ server to reply.
•
The tacacs-server key command defines the encryption key used for all TACACS+ communications between the NAS and the TACACS+ daemon.
The following example configures a generic TACACS+ server to grant a user, jim, reverse Telnet access to port tty2 on the NAS named godzilla and to port tty5 on the NAS named gamera:
Note
In this example, "godzilla" and "gamera" are the configured hostnames of network access servers, not DNS names or alias.
The following example configures the TACACS+ server (CiscoSecure) to grant a user named jim reverse Telnet access:
allow "c2511e0" "tty1" ".*"
password = clear "goaway"
Note
CiscoSecure only supports reverse Telnet using the command line interface in versions 2.1(x) through version 2.2(1).
An empty "service=raccess {}" clause permits a user to have unconditional access to NAS ports for reverse Telnet. If no "service=raccess" clause exists, the user is denied access to any port for reverse Telnet.
For more information about configuring TACACS+, refer to the "Configuring TACACS+" chapter. For more information about configuring CiscoSecure, refer to the CiscoSecure Access Control Server User Guide, version 2.1(2) or greater.
The following example causes the NAS to request authorization from a RADIUS security server before allowing a user to establish a reverse Telnet session:
aaa authentication login default radius
aaa authorization reverse-access radius
radius-server host 172.31.255.0
radius-server key go away
The lines in this sample RADIUS reverse Telnet authorization configuration are defined as follows:
•
The aaa new-model command enables AAA.
•
The aaa authentication login default radius command specifies RADIUS as the default method for user authentication during login.
•
The aaa authorization reverse-access radius specifies RADIUS as the method for user authorization when trying to establish a reverse Telnet session.
•
The radius-server host command identifies the RADIUS server.
•
The radius-server key command defines the encryption key used for all RADIUS communications between the NAS and the RADIUS daemon.
The following example configures the RADIUS server to grant a user named "jim" reverse Telnet access at port tty2 on the NAS named godzilla:
User-Service-Type = Shell-User
cisco-avpair = "raccess:port#1=godzilla/tty2"
The syntax "raccess:port=any/any" permits a user to have unconditional access to NAS ports for reverse Telnet. If no "raccess:port={nasname}/{tty number}" clause exists in the user profile, the user is denied access to reverse Telnet on all ports.
For more information about configuring RADIUS, refer to the "Configuring RADIUS" chapter.