Table Of Contents
Configuring RADIUS Attribute Screening
Verifying RADIUS Attribute Screening
Authorization Reject and Accounting Accept Example
Rejecting Required Attributes Example
RADIUS Attribute Screening
First Published: 12.2(1)DXLast Updated: February, 2006History for the RADIUS Attribute Screening Feature
Contents
Feature Overview
The RADIUS Attribute Screening feature allows users to configure a list of "accept" or "reject" RADIUS attributes on the network access server (NAS) for purposes such as authorization or accounting.
If a NAS accepts and processes all RADIUS attributes received in an Access-Accept packet, unwanted attributes may be processed, creating a problem for wholesale providers who do not control their customers' authentication, authorization, and accounting (AAA) servers. For example, there may be attributes that specify services to which the customer has not subscribed, or there may be attributes that may degrade service for other wholesale dial users. The ability to configure the NAS to restrict the use of specific attributes has therefore become a requirement for many users.
The RADIUS Attribute Screening feature should be implemented in one of the following ways:
•
To allow the NAS to accept and process all standard RADIUS attributes for a particular purpose, except for those on a configured reject list
•
To allow the NAS to reject (filter out) all standard RADIUS attributes for a particular purpose, except for those on a configured accept list
Benefits
The RADIUS Attribute Screening feature provides the following benefits:
Accept or Reject Lists
Users can configure an accept or reject list consisting of a selection of attributes on the NAS for a specific purpose so unwanted attributes are not accepted and processed.
Restricting Accept Lists to Relevant Accounting Attributes
Users might wish to configure an accept list that includes only relevant accounting attributes, thereby reducing unnecessary traffic and allowing users to customize their accounting data.
Restrictions
NAS Requirements
To enable this feature, your NAS should be configured for authorization with RADIUS groups.
Accept or Reject Lists Limitations
The two filters used to configure accept or reject lists are mutually exclusive; therefore, a user can configure only one access list or one reject list for each purpose, per server group.
Vendor-Specific Attributes
This feature does not support vendor-specific attribute (VSA) screening; however, a user can specify attribute 26 (Vendor-Specific) in an accept or reject list, which will accept or reject all VSAs.
Required Attributes Screening Recommendation
It is recommended that users do not reject the following required attributes:
•
For authorization:
–
6 (Service-Type)
–
7 (Framed-Protocol)
•
For accounting:
–
4 (NAS-IP-Address)
–
40 (Acct-Status-Type)
–
41 (Acct-Delay-Time)
–
44 (Acct-Session-ID)
If an attribute is required, the rejection will be refused, and the attribute will be allowed to pass through.
Note
The user will not receive an error at the point of configuring a reject list for required attributes because the list does not specify a purpose—authorization or accounting. The server will determine whether an attribute is required when it is known what the attribute is to be used for.
Prerequisites
Before configuring a RADIUS accept or reject list, you must enable AAA.
For more information, refer to the AAA chapters in the Cisco IOS Security Configuration Guide, Release 12.2.
Configuration Tasks
See the following section for configuration tasks for the RADIUS Attribute Screening feature. Each task in the list is identified as either optional or required.
•
Configuring RADIUS Attribute Screening (required)
•
Verifying RADIUS Attribute Screening (optional)
Configuring RADIUS Attribute Screening
To configure a RADIUS attribute accept or reject list for authorization or accounting, use the following commands beginning in global configuration mode:
Verifying RADIUS Attribute Screening
To verify an accept or reject list, use one of the following commands in privileged EXEC mode:
Configuration Examples
This section provides the following configuration examples:
•
Authorization Reject and Accounting Accept Example
•
Rejecting Required Attributes Example
Authorization Accept Example
The following example shows how to configure an accept list for attribute 6 (Service-Type) and attribute 7 (Framed-Protocol); all other attributes (including VSAs) are rejected for RADIUS authorization.
aaa new-modelaaa authentication ppp default group radius-sgaaa authorization network default group radius-sgaaa group server radius radius-sgserver 10.1.1.1authorization accept min-author!radius-server host 10.1.1.1 key mykey1radius-server attribute list min-authorattribute 6-7Accounting Reject Example
The following example shows how to configure a reject list for attribute 66 (Tunnel-Client-Endpoint) and attribute 67 (Tunnel-Server-Endpoint); all other attributes (including VSAs) are accepted for RADIUS accounting.
aaa new-modelaaa authentication ppp default group radius-sgaaa authorization network default group radius-sgaaa group server radius radius-sgserver 10.1.1.1accounting reject tnl-x-endpoint!radius-server host 10.1.1.1 key mykey1radius-server attribute list tnl-x-endpointattribute 66-67Authorization Reject and Accounting Accept Example
The following example shows how to configure a reject list for RADIUS authorization and configure an accept list for RADIUS accounting. Although you cannot configure more than one accept or reject list per server group for authorization or accounting, you can configure one list for authorization and one list for accounting per server group.
aaa new-modelaaa authentication ppp default group radius-sgaaa authorization network default group radius-sgaaa group server radius radius-sgserver 10.1.1.1authorization reject bad-authoraccounting accept usage-only!radius-server host 10.1.1.1 key mykey1radius-server attribute list usage-onlyattribute 1,40,42-43,46!radius-server attribute list bad-authorattribute 22,27-28,56-59Rejecting Required Attributes Example
The following example shows debug output for the debug aaa accounting command. In this example, required attributes 44, 40, and 41 have been added to the reject list:
Router# debug aaa authorizationAAA/ACCT(6): Accounting method=radius-sg (radius)RADIUS: attribute 44 cannot be rejectedRADIUS: attribute 61 rejectedRADIUS: attribute 31 rejectedRADIUS: attribute 40 cannot be rejectedRADIUS: attribute 41 cannot be rejectedAdditional References
The following sections provide references related to Radius Attribute Screening.
Related Documents
Related Topic Document TitleSecurity Commands
"Cisco IOS Security Command Reference", Release 12.4
Security Configuration Tasks
"Cisco IOS Security Configuration Guide", Release 12.4
Standards
MIBs
MIB MIBs LinkNone
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Command Reference
This section documents modified commands only.
accounting (server-group)
To specify an accept or reject list for attributes that are to be sent to the RADIUS server in an accounting request, use the accounting command in server-group configuration mode.
accounting [accept | reject] list-name
no accounting [accept | reject] list name
Syntax Description
Defaults
If specific attributes are not accepted or rejected, all attributes will be accepted.
Command Modes
Server-group configuration
Command History
Usage Guidelines
An accept or reject list (also known as a filter) for RADIUS accounting allows users to send only the accounting attributes their business requires, thereby reducing unnecessary traffic and allowing users to customize their own accounting data.
Only one filter may be used for RADIUS accounting per server group.
Note
The listname must be the same as the listname defined in the radius-server attribute list command, which is used with the attribute (server-group configuration) command to add to an accept or reject list.
Examples
The following example shows how to specify accept list "usage-only" for RADIUS accounting:
aaa new-modelaaa authentication ppp default group radius-sgaaa authorization network default group radius-sgaaa group server radius radius-sgserver 10.1.1.1accounting accept usage-only!radius-server host 10.1.1.1 key mykey1radius-server attribute list usage-onlyattribute 1,40,42-43,46Related Commands
authorization (server-group)
To filter attributes in outbound Access Requests to the RADIUS server for purposes of authentication or authorization, use the authorization command in server-group configuration mode. To remove the filter on the authorization request or reply, use the no form of the command.
authorization [request | reply] [accept | reject] list-name
no authorization [request | reply] [accept | reject] list-name
Syntax Description
Defaults
If specific attributes are not accepted or rejected, all attributes will be accepted.
Command Modes
Server-group configuration
Command History
Usage Guidelines
An accept or reject list (also known as a filter) for RADIUS authorization allows users to configure the network access server (NAS) to restrict the use of specific attributes, thereby preventing the NAS from processing unwanted attributes.
Only one filter may be used for RADIUS authorization per server group.
Note
The listname must be the same as the listname defined in the radius-server attribute list command, which is used with the attribute (server-group configuration) command to add to an accept or reject list.
Examples
The following example shows how to configure accept list "min-author" in an Access-Accept packet from the RADIUS server:
aaa new-modelaaa authentication ppp default group radius-sgaaa authorization network default group radius-sgaaa group server radius radius-sgserver 10.1.1.1authorization accept min-author!radius-server host 10.1.1.1 key mykey1radius-server attribute list min-authorattribute 6-7The following example shows that the attribute "all-attr" will be rejected in all outbound authorization Access Request messages:
aaa group server radius rasserver 172.19.192.238 auth-port 1745 acct-port 1746authorization request reject all-attrRelated Commands
attribute
To configure an attribute in a local service profile, use the attribute command in profile configuration mode. To delete an attribute from a service profile, use the no form of this command.
attribute radius-attribute-id [vendor-id] [cisco-vsa-type] attribute-value
no attribute radius-attribute-id [vendor-id] [cisco-vsa-type] attribute-value
Syntax Description
Defaults
For the Linterval option: If the L option is not defined, the accounting records for a service profile will be sent at the interval configured by the ssg accounting interval command. If the ssg accounting interval command is not set, the accounting records are sent every 600 seconds.
Otherwise, no default behavior or values are set.
Command Modes
Profile configuration
Command History
Usage Guidelines
Use this command to configure attributes in local service profiles.
For the SSG Open Garden feature, use this command to configure the Service Route, DNS Server Address, and Domain Name attributes in a local service profile before adding the service to the open garden.
To change the SSG accounting interval for a service profile, use the Linterval option in the attribute command. For example, if L80 is entered as the attribute value, the service profile sends accounting information every 80 seconds. Interim accounting can be disabled by entering the value (in seconds) as 0 (for instance, L0). When interim accounting is disabled, the normal accounting stops and starts are still sent.
For the SSG Hierarchical Policing feature, use the Q option to configure the token bucket parameters (token rate, normal burst, and excess burst). The syntax for the Q option is as follows:
Router(config-prof)# attribute radius-attribute-id vendor-id cisco-vsa-type "QU;upstream-committed-rate;upstream-normal-burst; [upstream-excess-burst];D;downstream-committed-rate; downstream-normal-burst;[downstream-excess-burst]"
The variables are used to configure upstream (U) and downstream (D) policing. The upstream traffic is the traffic that travels from the subscriber to the network, and the downstream traffic is the traffic that travels from the network to the subscriber.
Examples
In the following example, the Cisco AV pair Upstream Access Control List (inacl) attribute is configured in the local service profile called "cisco.com":
Router(config)# local-profile cisco.comRouter(config-prof)# attribute 26 9 1 "ip:inacl#101=deny tcp 10.2.1.0 0.0.0.255 any eq 21"In the following example, the Session-Timeout attribute is deleted from the local service profile called "cisco.com":
Router(config)# local-profile cisco.comRouter(config-prof)# no attribute 27 600In the following example, the local profile "cisco.com" is configured to send an interim accounting update every 90 seconds:
Router(config)# local-profile cisco.comRouter(config-prof)# attribute 26 9 1 "L90"In the following example, the SSG Hierarchical Policing parameters are set for upstream and downstream traffic:
Router(config)# local-profile cisco.comRouter(config-prof)# attribute 26 9 251 "QU:8000:16000:20000:D10000:20000:30000"In the following example, an open garden service called "opencisco.com" is defined.
Router(config)# local-profile opencisco.comRouter(config-prof)# attribute 26 9 251 "Oopengarden1.com"Router(config-prof)# attribute 26 9 251 "D10.13.1.5"Router(config-prof)# attribute 26 9 251 "R10.1.1.0;255.255.255.0"Router(config-prof)# exitRouter(config)# ssg open-garden opencisco.comRelated Commands
radius-server attribute list
To define an accept or reject list name, use the radius-server attribute list command in global configuration mode. To remove an accept or reject list name from your configuration, use the no form of this command.
radius-server attribute list list-name
no radius-server attribute list list-name
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
A user may configure an accept or reject list with a selection of attributes on the network access server (NAS) for authorization or accounting so unwanted attributes are not accepted and processed. The radius-server attribute list command allows users to specify a name for an accept or reject list. This command is used in conjunction with the attribute (server-group configuration) command, which adds attributes to an accept or reject list.
Note
The listname must be the same as the listname defined in the accounting or authorization configuration command.
Examples
The following example shows how to configure the reject list "bad-author" for RADIUS authorization and accept list "usage-only" for RADIUS accounting:
Router(config)# aaa new-modelRouter(config)# aaa authentication ppp default group radius-sgRouter(config)# aaa authorization network default group radius-sgRouter(config)# aaa group server radius radius-sgRouter(config-sg-radius)# server 10.1.1.1Router(config-sg-radius)# authorization reject bad-authorRouter(config-sg-radius)# accounting accept usage-onlyRouter(config-sg-radius)# exitRouter(config)# radius-server host 10.1.1.1 key mykey1Router(config)# radius-server attribute list usage-onlyRouter(config-radius-attrl)# attribute 1,40,42-43,46Router(config-radius-attrl)# exitRouter(config)# radius-server attribute list bad-authorRouter(config-radius-attrl)# attribute 22,27-28,56-59
Note
Although you cannot configure more than one access or reject list per server group for authorization or accounting, you can configure one list for authorization and one list for accounting per server group.
Related Commands
Glossary
AAA—Authentication, authorization, and accounting. Suite of network security services that provide the primary framework through which access control can be set up on your Cisco router or access server.
attribute—RADIUS Internet Engineering Task Force (IETF) attributes are the original set of 255 standard attributes that are used to communicate AAA information between a client and a server. Because IETF attributes are standard, the attribute data is predefined and well known; thus all clients and servers who exchange AAA information via IETF attributes must agree on attribute data such as the exact meaning of the attributes and the general bounds of the values for each attribute.
NAS—Network access server. A Cisco platform (or collection of platforms, such as an AccessPath system) that interfaces between the packet world (for example, the Internet) and the circuit world (for example, the Public Switched Telephone Network).
RADIUS—Remote Authentication Dial-In User Service. RADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.
VSA—Vendor-specific attribute. VSAs are derived from one IETF attribute—vendor-specific (attribute 26). Attribute 26 allows a vendor to create and implement an additional 255 attributes. That is, a vendor can create an attribute that does not match the data of any IETF attribute and encapsulate it behind attribute 26; essentially, Vendor-Specific ="protocol:attribute=value".
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2001-2002, 2006 Cisco Systems, Inc. All rights reserved.


