- Securing User Services Overview
- Autosecure
-
-
-
- Configuring RADIUS
- AAA Dead-Server Detection
- ACL Default Direction
- Attribute Screening for Access Requests
- Enable Multilink PPP via RADIUS for Preauthentication User
- Enhanced Test Command
- Framed-Route in RADIUS Accounting
- Offload Server Accounting Enhancement
- Per VRF AAA
- RFC-2867 RADIUS Tunnel Accounting
- RADIUS Attribute Screening
- RADIUS Centralized Filter Management
- RADIUS Debug Enhancements
- RADIUS Logical Line ID
- RADIUS NAS-IP-Address Attribute Configurability
- RADIUS Route Download
- RADIUS Support of 56-Bit Acct Session-Id
- RADIUS Tunnel Preference for Load Balancing and Fail-Over
- RADIUS Server Reorder on Failure
- Tunnel Authentication via RADIUS on Tunnel Terminator
-
-
-
- RADIUS Attributes Overview and RADIUS IETF Attributes
- RADIUS Vendor-Proprietary Attributes
- Vendor-Specific Attributes (VSA) and RADIUS Disconnect-Cause Attribute Values
- Connect-Info RADIUS Attribute 77
- Encrypted Vendor Specific Attributes
- Local AAA Server
- Per-User QoS via AAA Policy Name
- RADIUS Attribute 5 (NAS-Port) Format Specified on a Per-Server Group Level
- RADIUS Attribute 8 (Framed-IP-Address) in Access Requests
- RADIUS Attribute 82: Tunnel Assignment ID
- RADIUS Attribute 104
- RADIUS Progress Codes
- RADIUS Timeout Set During Pre-Authentication
- RADIUS Tunnel Attribute Extensions
- V.92 Reporting Using RADIUS Attribute v.92-info
-
- Cisco IOS Login Enhancements (Login Block)
- Cisco IOS Resilient Configuration
- Image Verification
- IP Source Tracker
- Role-Based CLI Access
Configuring Authorization
The AAA authorization feature is used to determine what a user can and cannot do. 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 is granted access to a requested service only if the information in the user profile allows it.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Configuring Authorization" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Information About Configuring Authorization
•How to Configure Authorization
•Authorization Configuration Examples
•Feature Information for Configuring Authorization
Prerequisites
Before configuring authorization using named method lists, the following tasks must be performed:
•Enable AAA on your network access server.
•Configure AAA authentication. Authorization generally takes place after authentication and relies on authentication to work properly.
•Define the characteristics of your Lightweight Directory Access Protocol (LDAP), RADIUS, or TACACS+ security server if RADIUS or TACACS+ authorization is issued so that the Cisco network access server can communicate with the RADIUS or TACACS+ security server.
•Define the rights associated with specific users by using the username command if local authorization is issued.
•See the "Related Documents" section for more information on documents related to these prerequisites.
Information About Configuring Authorization
The following sections provide information about how the Authorization feature is configured:
•Named Method Lists for Authorization
•Method Lists and Server Groups
•Authorization Attribute-Value Pairs
Named Method Lists for Authorization
Method lists for authorization define the ways that authorization is performed and the sequence in which these methods are performed. A method list is simply a named list describing the authorization methods to be queried (such as LDAP, RADIUS, or TACACS+), in sequence. Method lists enable one or more security protocols to be used for authorization, thus ensuring a backup system in case the initial method fails. Cisco IOS software uses the first method listed to authorize users for specific network services; if that method fails to respond, the Cisco IOS software selects the next method listed in the method list. This process continues until there is successful communication with a listed authorization method, or all methods defined are exhausted.
Note The Cisco IOS software attempts authorization with the next listed method only when there is no response from the previous method. If authorization fails at any point in this cycle—meaning that the security server or local username database responds by denying the user services—the authorization process stops and no other authorization methods are attempted.
Method lists are specific to the authorization type requested:
•Auth-proxy—Applies specific security policies on a per-user basis. See "Related Documents" section for more information about where to find authentication proxy configuration documentation.
•Commands—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.
•EXEC—Applies to the attributes associated with a user EXEC terminal session.
•Network—Applies to network connections. This can include a PPP, SLIP, or ARAP connection.
•Reverse Access—Applies to reverse Telnet sessions.
When a named method list is created, a particular list of authorization methods for the indicated authorization type is defined.
Once defined, method lists must be applied to specific lines or interfaces before any of the defined methods are performed. The only exception is the default method list (which is named "default"). If the aaa authorization command for a particular authorization type is issued without a named method list specified, the default method list is automatically applied to all interfaces or lines except those that have a named method list explicitly defined. (A defined method list overrides the default method list.) If no default method list is defined, local authorization takes place by default.
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.
•None—The network access server does not request authorization information; authorization is not performed over this line/interface.
•Local—The router or access server consults its local database, as defined by the username command, for example, to authorize specific rights for users. Only a limited set of functions can be controlled through the local database.
•LDAP—The network access server requests authorization information from the RADIUS security server. LDAP authorization defines specific rights for users by associating attributes, which are stored in a database on the LDAP server, with the appropriate user.
•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.
Authorization Methods
To have the network access server request authorization information through a TACACS+ security server, use the aaa authorization command with the group tacacs+ method keyword. For more specific information about configuring authorization using a TACACS+ security server, see the "Configuring TACACS+" feature module. 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: Examples" section for more information.
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 this method is selected, all requested functions are automatically granted to authenticated users.
There may be times when it is not desirable to run authorization from a particular interface or line. To stop authorization activities on designated lines or interfaces, use the none method keyword. If this method is selected, authorization is disabled for all actions.
To select local authorization, which means that the router or access server consults its local user database to determine the functions a user is permitted to use, 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, see the "Configuring Authentication" feature module.
To have the network access server request authorization through a LDAP security server, use the ldap method keyword. For more specific information about configuring authorization using a RADIUS security server, see the "Configuring RADIUS" feature module
To have the network access server request authorization through a RADIUS security server, use the radius method keyword. For more specific information about configuring authorization using a RADIUS security server, see the "Configuring RADIUS" feature module.
To have the network access server request authorization through a RADIUS security server, use the aaa authorization command with the group radius method keyword. For more specific information about configuring authorization using a RADIUS security server, see the "Configuring RADIUS" feature module. For an example of how to enable a RADIUS server to authorize services, see the "RADIUS Authorization: Example" section for more information.
Note Authorization method lists for SLIP follow whatever is configured for PPP on the relevant interface. If no lists are defined and applied to a particular interface (or no PPP settings are configured), the default setting for authorization applies.
Method Lists and Server Groups
A server group is a way to group existing LDAP, RADIUS, or TACACS+ server hosts for use in method lists. Figure 1 shows a typical AAA network configuration that includes four security servers: R1 and R2 are RADIUS servers, and T1 and T2 are TACACS+ servers. R1 and R2 make up the group of RADIUS servers. T1 and T2 make up the group of TACACS+ servers.
Figure 1 Typical AAA Network Configuration
Using server groups, a subset of the configured server hosts can be specified and use them for a particular service. For example, server groups allows R1 and R2 to be defined as separate server groups, and T1 and T2 as separate server groups. This allows either R1 and T1 to be specified in the method list or R2 and T2 in the method list, which provides more flexibility in the way that RADIUS and TACACS+ resources are assigned.
Server groups also can include multiple host entries for the same server, as long as each entry has a unique identifier. The combination of an IP address and a UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. In other words, this unique identifier enables RADIUS requests to be sent to different UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, authorization—the second host entry configured acts as fail-over backup to the first one. Using this example, if the first host entry fails to provide accounting services, the network access server tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order they are configured.)
For more information about configuring server groups and about configuring server groups based on DNIS numbers. See the "Configuring LDAP", "Configuring RADIUS" or "Configuring TACACS+" feature modules.
AAA Authorization Types
Cisco IOS software supports five different types of authorization:
•Auth-proxy—Applies specific security policies on a per-user basis. See "Related Documents" section for more information about where to find authentication proxy configuration documentation.
•Commands—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.
•EXEC—Applies to the attributes associated with a user EXEC terminal session.
•Network—Applies to network connections. This can include a PPP, SLIP, or ARAP connection.
•Reverse Access—Applies to reverse Telnet sessions.
•Configuration—Applies to downloading configurations from the AAA server.
•IP Mobile—Applies to authorization for IP mobile services.
Authorization Types
Named authorization method lists are specific to the indicated type of authorization.
To create a method list to enable authorization that applies specific security policies on a per-user basis, use the auth-proxy keyword. See "Related Documents" section for more information about where to find authentication proxy configuration documentation.
To create a method list to enable authorization for all network-related service requests (including SLIP, PPP, PPP NCPs, and ARAP), use the network keyword.
To create a method list to enable authorization to determine if a user is allowed to run an EXEC shell, use the exec keyword.
To create a method list to enable authorization for specific, individual EXEC commands associated with a specific privilege level, use the commands keyword. (This allows all commands associated with a specified command level from 0 to 15 to be authorized.)
To create a method list to enable authorization for reverse Telnet functions, use the reverse-access keyword.
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.
See "Related Documents" section for more information about supported RADIUS attributes and TACACS+ attribute-value pair documentation.
How to Configure Authorization
This section describes the following configuration tasks:
•Configuring AAA Authorization Using Named Method Lists
•Disabling Authorization for Global Configuration Commands
•Configuring Authorization for Reverse Telnet
See "Authorization Configuration Examples" section for more information.
Configuring AAA Authorization Using Named Method Lists
Perform this task to configure AAA authorization using named method lists:
SUMMARY STEPS
1. enable
2. configure terminal
3. aaa authorization {auth-proxy | network | exec | commands level | reverse-access | configuration | ipmobile} {default | list-name} [method1 [method2...]]
4. line [aux | console | tty | vty] line-number [ending-line-number]
5. authorization {arap | commands level | exec | reverse-access} {default | list-name}
DETAILED STEPS
Disabling Authorization for Global Configuration Commands
The aaa authorization command with the keyword commands 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 from attempting configuration command authorization.
To disable AAA authorization for all global configuration commands, use the following command in global configuration mode:
|
|
---|---|
Router(config)# no aaa authorization config-commands |
Disables authorization for all global configuration commands. |
Configuring Authorization for Reverse Telnet
Telnet is a standard terminal emulation protocol used for remote terminal connection. Normally, a network access server is logged into and then Telnet is used to access other network devices from that network access server. 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 network access server on the network periphery to gain access to modems or other devices connected to that network access server. Reverse Telnet is used to provide users with dialout capability by allowing them to Telnet to modem ports attached to a network access server.
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 network access server to request authorization information from a TACACS+ or RADIUS server before allowing a user to establish a reverse Telnet session, use the following command in global configuration mode:
This feature enables the network access server to request reverse Telnet authorization information from the security server, whether RADIUS or TACACS+. The specific reverse Telnet privileges for the user on the security server itself must be configured.
Authorization Configuration Examples
The following sections provide authorization configuration examples:
•Named Method List Configuration: Example
•TACACS+ Authorization: Examples
•RADIUS Authorization: Example
•Reverse Telnet Authorization: Examples
Named Method List Configuration: Example
The following example shows how to configure a Cisco AS5300 (enabled for AAA and communication with a RADIUS security server) for AAA services to be provided by the RADIUS server. If the RADIUS server fails to respond, then the local database is queried for authentication and authorization information, and accounting services are handled by a TACACS+ server.
aaa new-model
aaa authentication login admins local
aaa authentication ppp dialins group radius local
aaa authorization network scoobee group radius local
aaa accounting network charley start-stop group radius
username root password ALongPassword
radius-server host alcatraz
radius-server key myRaDiUSpassWoRd
interface group-async 1
group-range 1 16
encapsulation ppp
ppp authentication chap dialins
ppp authorization scoobee
ppp accounting charley
line 1 16
autoselect ppp
autoselect during-login
login authentication admins
modem dialin
The lines in this sample RADIUS AAA configuration are defined as follows:
•The aaa new-model command enables AAA network security services.
•The aaa authentication login admins local command defines a method list, admins, for login authentication.
•The aaa authentication ppp dialins group radius local command defines the authentication method list "dialins," which specifies that RADIUS authentication then (if the RADIUS server does not respond) local authentication is used on serial lines using PPP.
•The aaa authorization network scoobee group radius local command defines the network authorization method list named scoobee, which specifies that RADIUS authorization is used on serial lines using PPP. If the RADIUS server fails to respond, then local network authorization is performed.
•The aaa accounting network charley start-stop group radius command defines the network accounting method list named charley, which specifies that RADIUS accounting services (in this case, start and stop records for specific events) are used on serial lines using PPP.
•The username command defines the username and password to be used for the PPP Password Authentication Protocol (PAP) caller identification.
•The radius-server host command defines the name of the RADIUS server host.
•The radius-server key command defines the shared secret text string between the network access server and the RADIUS server host.
•The interface group-async command selects and defines an asynchronous interface group.
•The group-range command defines the member asynchronous interfaces in the interface group.
•The encapsulation ppp command sets PPP as the encapsulation method used on the specified interfaces.
•The ppp authentication chap dialins command selects Challenge Handshake Authentication Protocol (CHAP) as the method of PPP authentication and applies the "dialins" method list to the specified interfaces.
•The ppp authorization scoobee command applies the scoobee network authorization method list to the specified interfaces.
•The ppp accounting charley command applies the charley network accounting method list to the specified interfaces.
•The line command switches the configuration mode from global configuration to line configuration and identifies the specific lines being configured.
•The autoselect ppp command configures the Cisco IOS software to allow a PPP session to start up automatically on these selected lines.
•The autoselect during-login command is used to display the username and password prompt without pressing the Return key. After the user logs in, the autoselect function (in this case, PPP) begins.
•The login authentication admins command applies the admins method list for login authentication.
•The modem dialin command configures modems attached to the selected lines to only accept incoming calls.
TACACS+ Authorization: Examples
The following examples show how to use 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 default group tacacs+ none
The following example shows how to allow network authorization using TACACS+:
aaa authorization network default group tacacs+
The following example shows how to provide the same authorization, but it also creates address pools called mci and att:
aaa authorization network default group tacacs+
ip address-pool local
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:
user = mci_customer1 {
login = cleartext "some password"
service = ppp protocol = ip {
addr-pool=mci
}
}
user = att_customer1 {
login = cleartext "some other password"
service = ppp protocol = ip {
addr-pool=att
}
RADIUS Authorization: Example
The following example shows how to configure the router to authorize using RADIUS:
aaa new-model
aaa authorization exec default group radius if-authenticated
aaa authorization network default group radius
radius-server host ip
radius-server key
The lines in this sample RADIUS authorization configuration are defined as follows:
•The aaa authorization exec default group 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 log in. 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 default group radius command configures network authorization through 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 fails if, for any reason, there is no response from the RADIUS server.
LDAP Authorization: Example
The following example shows how to configure the router to authorize using LDAP:
aaa new-model
aaa authorization exec default group ldap if-authenticated
aaa authorization network default group ldap
The lines in this sample RADIUS authorization configuration are defined as follows:
•The aaa authorization exec default group ldap if-authenticated command configures the network access server to contact the LDAP server to determine if users are permitted to start an EXEC shell when they log in. If an error occurs when the network access server contacts the LDAP server, the fallback method is to permit the CLI to start, provided the user has been properly authenticated.
The LDAP information returned may be used to specify an autocommand or a connection access list be applied to this connection.
The aaa authorization network default group ldap command configures network authorization through LDAP. This command can be used to govern address assignment, the application of access lists, and various other per-user quantities.
Reverse Telnet Authorization: Examples
The following examples show how to cause the network access server to request authorization information from a TACACS+ security server before allowing a user to establish a reverse Telnet session:
aaa new-model
aaa authentication login default group tacacs+
aaa authorization reverse-access default group tacacs+
!
tacacs-server host 172.31.255.0
tacacs-server timeout 90
tacacs-server key goaway
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 group tacacs+ command specifies TACACS+ as the default method for user authentication during login.
•The aaa authorization reverse-access default group tacacs+ command 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 network access server waits for the TACACS+ server to reply.
•The tacacs-server key command defines the encryption key used for all TACACS+ communications between the network access server and the TACACS+ daemon.
The following example shows how to configure a generic TACACS+ server to grant a user, pat, reverse Telnet access to port tty2 on the network access server named "maple" and to port tty5 on the network access server named "oak":
user = pat
login = cleartext lab
service = raccess {
port#1 = maple/tty2
port#2 = oak/tty5
Note In this example, "maple" and "oak" are the configured host names of network access servers, not DNS names or alias.
The following example shows how to configure the TACACS+ server (CiscoSecure) to grant a user named pat reverse Telnet access:
user = pat
profile_id = 90
profile_cycle = 1
member = Tacacs_Users
service=shell {
default cmd=permit
}
service=raccess {
allow "c2511e0" "tty1" ".*"
refuse ".*" ".*" ".*"
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 network access server ports for reverse Telnet. If no "service=raccess" clause exists, the user is denied access to any port for reverse Telnet.
The following example shows how to cause the network access server to request authorization from a RADIUS security server before allowing a user to establish a reverse Telnet session:
aaa new-model
aaa authentication login default group radius
aaa authorization reverse-access default group radius
!
radius-server host 172.31.255.0
radius-server key go away
auth-port 1645 acct-port 1646
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 group radius command specifies RADIUS as the default method for user authentication during login.
•The aaa authorization reverse-access default group radius command 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 network access server and the RADIUS daemon.
The following example shows how to send a request to the RADIUS server to grant a user named "pat" reverse Telnet access at port tty2 on the network access server named "maple":
Username = "pat"
Password = "goaway"
User-Service-Type = Shell-User
cisco-avpair = "raccess:port#1=maple/tty2"
The syntax "raccess:port=any/any" permits a user to have unconditional access to network access server 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.
Additional References
The following sections provide references related to the Authorization feature.
Related Documents
|
|
---|---|
Authorization Commands |
|
RADIUS |
"Configuring RADIUS" feature module. |
LDAP |
Configuring RADIUS feature Module. |
RADIUS attributes |
"RADIUS Attributes Overview and RADIUS IETF Attributes" feature module. |
TACACS+ |
"Configuring TACACS+" feature module. |
TACACS+ Attribute-Value Pairs |
"TACACS+ Attribute-Value Pairs" feature module. |
Authentication |
"Configuring Authentication" feature module. |
Authentication Proxy |
"Configuring Authentication Proxy" feature module. |
Standards
|
|
---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
— |
MIBs
|
|
---|---|
None. |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
RFCs
|
|
---|---|
No new or modified RFCs are supported by this feature. |
— |
Technical Assistance
Feature Information for Configuring Authorization
Table 1 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp. An account on Cisco.com is not required.
Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.