Cisco Asdm 7 User Guide

							 
8-11
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Authentication for Network Access
that requires authentication is allowed through. If you do not want to allow HTTP, Telnet, or FTP traffic 
through the ASA, but want to authenticate other types of traffic, you can configure virtual Telnet; the 
user Telnets to a given IP address configured on the ASA, and the ASA issues a Telnet prompt.
When an unauthenticated user connects to the virtual Telnet IP address, the user is challenged for a 
username and password, and then authenticated by the AAA server. After the user is authenticated, the 
message “Authentication Successful” appears. Then the user can successfully access other services that 
require authentication.
For inbound users (from lower security to higher security), you must also include the virtual Telnet 
address as a destination interface in the access rule applied to the source interface. In addition, you must 
add a static NAT rule for the virtual Telnet IP address, even if NAT is not required. An identity NAT rule 
is typically used (where you translate the address to itself).
For outbound users, there is an explicit permit for traffic, but if you apply an access rule to an inside 
interface, be sure to allow access to the virtual Telnet address. A static NAT rule is not required.
To log out from the ASA, reconnect to the virtual Telnet IP address; you are prompted to log out.
To enable direct authentication using Telnet, perform the following steps:
Step 1In the Configuration > Firewall > Advanced > Virtual Access > Virtual Telnet Server area, check the 
Enable check box.
Step 2In the Virtual Telnet Server field, enter the IP address of the virtual Telnet server.
Make sure that this address is an unused address that is routed to the ASA. For example, if you perform 
NAT for inside addresses accessing an outside server, and you want to provide outside access to the 
virtual HTTP server, you can use one of the global NAT addresses for the virtual HTTP server address.
Step 3Click Apply.
The virtual server is added and the changes are saved to the running configuration.
Configuring the Authentication Proxy Limit
You can manually configure the uauth session limit by setting the maximum number of concurrent proxy 
connections allowed per user.
To set the proxy limit, perform the following steps:
Step 1Choose Configuration > Firewall > AAA Rules, then click Advanced.
The AAA Rules Advanced Options dialog box appears.
Step 2In the Proxy Limit area, check the Enable Proxy Limit check box.
Step 3In the Proxy Limit field, enter the number of concurrent proxy connections allowed per user, from 1 to 
128.
Step 4Click OK, then click Apply.
The changes are saved to the running configuration. 
						

							 
8-12
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Authorization for Network Access
Configuring Authorization for Network Access
After a user authenticates for a given connection, the ASA can use authorization to further control traffic 
from the user.
This section includes the following topics:
Configuring TACACS+ Authorization, page 8-12
Configuring RADIUS Authorization, page 8-13
Configuring TACACS+ Authorization
You can configure the ASA to perform network access authorization with TACACS+. Authentication and 
authorization statements are independent; however, any unauthenticated traffic matched by an 
authorization rule will be denied.For authorization to succeed:
1.A user must first authenticate with the ASA.
Because a user at a given IP address only needs to authenticate one time for all rules and types, if 
the authentication session has not expired, authorization can occur even if the traffic is not matched 
by an authentication rule.
2.After a user authenticates, the ASA checks the authorization rules for matching traffic.
3.If the traffic matches the authorization rule, the ASA sends the username to the TACACS+ server.
4.The TACACS+ server responds to the ASA with a permit or a deny for that traffic, based on the user 
profile.
5.The ASA enforces the authorization rule in the response.
See the documentation for your TACACS+ server for information about configuring network access 
authorizations for a user.
To configure TACACS+ authorization, perform the following steps:
Step 1Enable authentication. For more information, see the “Configuring Network Access Authentication” 
section on page 8-6. If you have already enabled authentication, continue to the next step.
Step 2In the Configuration > Firewall > AAA Rules pane, choose Add > Add Authorization Rule.
The Add Authorization Rule dialog box appears.
Step 3In the Interface drop-down list, choose the interface for applying the rule.
Step 4In the Action field, click one of the following, depending on the implementation:
Au t h or iz e 
Do not Authorize
Step 5In the AAA Server Group drop-down list, choose a server group. To add a AAA server to the server 
group, click Add Server.
Only TACACS+ servers are supported.
Step 6In the Source field, add the source IP address, or click the ellipsis (...) to choose an IP address already 
defined in ASDM.
Step 7In the Destination field, enter the destination IP address, or click the ellipsis (...) to choose an IP address 
already defined in ASDM. 
						

							 
8-13
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Authorization for Network Access
Step 8In the Service field, enter an IP service name or number for the destination service, or click the ellipsis 
(...) to choose a service.
Step 9(Optional) In the Description field, enter a description.
Step 10(Optional) Click More Options to do any of the following:
To specify a source service for TCP or UDP, enter a TCP or UDP service in the Source Service field.
The destination service and source service must be the same. Copy and paste the Destination Service 
field content into the Source Service field.
To make the rule inactive, clear the Enable Rule check box.
You may not want to remove a rule, but instead turn it off.
To set a time range for the rule, in the Time Range drop-down list, choose an existing time range. 
To add a new time range, click the ellipsis (...). For more information, see the “Configuring Time 
Ranges” section on page 20-26 in the general operations configuration guide.
Step 11Click OK.
The Add Authorization Rule dialog box closes, and the rule appears in the AAA Rules table.
Step 12Click Apply.
The changes are saved to the running configuration.
Configuring RADIUS Authorization
When authentication succeeds, the RADIUS protocol returns user authorizations in the access-accept 
message sent by a RADIUS server. For more information about configuring authentication, see the 
“Configuring Network Access Authentication” section on page 8-6.
When you configure the ASA to authenticate users for network access, you are also implicitly enabling 
RADIUS authorizations; therefore, this section contains no information about configuring RADIUS 
authorization on the ASA. It does provide information about how the ASA handles ACL information 
received from RADIUS servers.
You can configure a RADIUS server to download an ACL to the ASA or an ACL name at the time of 
authentication. The user is authorized to do only what is permitted in the user-specific ACL.
NoteIf you have enabled the Per User Override Setting (see the Configuration > Firewall > Access Rules > 
Advanced > Access Rules Advanced Options dialog box), be aware of the following effects of the 
per-user-override featureon authorization by user-specific ACLs: 
Without the per-user-override feature, traffic for a user session must be permitted by both the 
interface ACL and the user-specific ACL.
With the per-user-override feature, the user-specific ACL determines what is permitted.
This section includes the following topics:
Configuring a RADIUS Server to Send Downloadable Access Control Lists, page 8-14
Configuring a RADIUS Server to Download Per-User Access Control List Names, page 8-17 
						

							 
8-14
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Authorization for Network Access
Configuring a RADIUS Server to Send Downloadable Access Control Lists
This section describes how to configure Cisco Secure ACS or a third-party RADIUS server and includes 
the following topics:
About the Downloadable ACL Feature and Cisco Secure ACS, page 8-14
Configuring Cisco Secure ACS for Downloadable ACLs, page 8-15
Configuring Any RADIUS Server for Downloadable ACLs, page 8-16
Converting Wildcard Netmask Expressions in Downloadable ACLs, page 8-17
About the Downloadable ACL Feature and Cisco Secure ACS
Downloadable ACLs is the most scalable means of using Cisco Secure ACS to provide the appropriate 
ACLs for each user. It provides the following capabilities:
Unlimited ACL size—Downloadable ACLs are sent using as many RADIUS packets as required to 
transport the full ACL from Cisco Secure ACS to the ASA.
Simplified and centralized management of ACLs—Downloadable ACLs enable you to write a set of 
ACLs once and apply it to many user or group profiles and distribute it to many ASAs.
This approach is most useful when you have very large ACL sets that you want to apply to more than 
one Cisco Secure ACS user or group; however, its ability to simplify Cisco Secure ACS user and group 
management makes it useful for ACLs of any size.
The ASA receives downloadable ACLs from Cisco Secure ACS using the following process:
1.The ASA sends a RADIUS authentication request packet for the user session.
2.If Cisco Secure ACS successfully authenticates the user, Cisco Secure ACS returns a RADIUS 
access-accept message that includes the internal name of the applicable downloadable ACL. The 
Cisco IOS cisco-av-pair RADIUS VSA (vendor 9, attribute 1) includes the following attribute-value 
pair to identify the downloadable ACL set:
ACS:CiscoSecure-Defined-ACL=acl-set-name
where acl-set-name is the internal name of the downloadable ACL, which is a combination of the 
name assigned to the ACL by the Cisco Secure ACS administrator and the date and time that the 
ACL was last modified.
3.The ASA examines the name of the downloadable ACL and determines if it has previously received 
the named downloadable ACL.
–If the ASA has previously received the named downloadable ACL, communication with Cisco 
Secure ACS is complete and the ASA applies the ACL to the user session. Because the name of 
the downloadable ACL includes the date and time that it was last modified, matching the name 
sent by Cisco Secure ACS to the name of an ACL previously downloaded means that the ASA 
has the most recent version of the downloadable ACL.
–If the ASA has not previously received the named downloadable ACL, it may have an 
out-of-date version of the ACL or it may not have downloaded any version of the ACL. In either 
case, the ASA issues a RADIUS authentication request using the downloadable ACL name as 
the username in the RADIUS request and a null password attribute. In a cisco-av-pair RADIUS 
VSA, the request also includes the following attribute-value pairs:
AAA:service=ip-admission
AAA:event=acl-download
In addition, the ASA signs the request with the Message-Authenticator attribute (IETF RADIUS 
attribute 80). 
						

							 
8-15
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Authorization for Network Access
4.After receipt of a RADIUS authentication request that has a username attribute that includes the 
name of a downloadable ACL, Cisco Secure ACS authenticates the request by checking the 
Message-Authenticator attribute. If the Message-Authenticator attribute is missing or incorrect, 
Cisco Secure ACS ignores the request. The presence of the Message-Authenticator attribute 
prevents malicious use of a downloadable ACL name to gain unauthorized network access. The 
Message-Authenticator attribute and its use are defined in RFC 2869, RADIUS Extensions, 
available at http://www.ietf.org.
5.If the ACL required is less than approximately 4 KB in length, Cisco Secure ACS responds with an 
access-accept message that includes the ACL. The largest ACL that can fit in a single access-accept 
message is slightly less than 4 KB, because part of the message must be other required attributes.
Cisco Secure ACS sends the downloadable ACL in a cisco-av-pair RADIUS VSA. The ACL is 
formatted as a series of attribute-value pairs that each include an ACE and are numbered serially:
ip:inacl#1=ACE-1
ip:inacl#2=ACE-2
.
.
.
ip:inacl#n=ACE-n
ip:inacl#1=permit tcp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
6.If the ACL required is more than approximately 4 KB in length, Cisco Secure ACS responds with 
an access-challenge message that includes a portion of the ACL, formatted as described previously, 
and a State attribute (IETF RADIUS attribute 24), which includes control data used by Cisco Secure 
ACS to track the progress of the download. Cisco Secure ACS fits as many complete attribute-value 
pairs into the cisco-av-pair RADIUS VSA as it can without exceeding the maximum RADIUS 
message size.
The ASA stores the portion of the ACL received and responds with another access-request message 
that includes the same attributes as the first request for the downloadable ACL, plus a copy of the 
State attribute received in the access-challenge message.
This process repeats until Cisco Secure ACS sends the last of the ACL in an access-accept message.
Configuring Cisco Secure ACS for Downloadable ACLs
You can configure downloadable ACLs on Cisco Secure ACS as a shared profile component and then 
assign the ACL to a group or to an individual user.
The ACL definition consists of one or more ASA commands that are similar to the extended access-list 
command (see command reference), except without the following prefix:
access-list acl_name extended
The following example is a downloadable ACL definition on Cisco Secure ACS version 3.3:
+--------------------------------------------+
| Shared profile Components                  |
|                                            |
|      Downloadable IP ACLs Content          |
|                                            |
| Name:    acs_ten_acl                       |
|                                            |
|      ACL Definitions                       |
|                                            |
| permit tcp any host 10.0.0.254             |
| permit udp any host 10.0.0.254             |
| permit icmp any host 10.0.0.254            |
| permit tcp any host 10.0.0.253             | 
						

							 
8-16
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Authorization for Network Access
| permit udp any host 10.0.0.253             |
| permit icmp any host 10.0.0.253            |
| permit tcp any host 10.0.0.252             |
| permit udp any host 10.0.0.252             |
| permit icmp any host 10.0.0.252            |
| permit ip any any                          |
+--------------------------------------------+
For more information about creating downloadable ACLs and associating them with users, see the user 
guide for your version of Cisco Secure ACS.
On the ASA, the downloaded ACL has the following name:
#ACSACL#-ip-acl_name-number
The acl_name argument is the name that is defined on Cisco Secure ACS (acs_ten_acl in the preceding 
example), and number is a unique version ID generated by Cisco Secure ACS.
The downloaded ACL on the ASA consists of the following lines:
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit tcp any host 10.0.0.254
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit udp any host 10.0.0.254
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit icmp any host 10.0.0.254
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit tcp any host 10.0.0.253
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit udp any host 10.0.0.253
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit icmp any host 10.0.0.253
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit tcp any host 10.0.0.252
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit udp any host 10.0.0.252
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit icmp any host 10.0.0.252
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit ip any any
Configuring Any RADIUS Server for Downloadable ACLs
You can configure any RADIUS server that supports Cisco IOS RADIUS VSAs to send user-specific 
ACLs to the ASA in a Cisco IOS RADIUS cisco-av-pair VSA (vendor 9, attribute 1).
In the cisco-av-pair VSA, configure one or more ACEs that are similar to the access-list extended 
command (see command reference), except that you replace the following command prefix:
access-list acl_name extended
with the following text:
ip:inacl#nnn=
The nnn argument is a number in the range from 0 to 999999999 that identifies the order of the command 
statement to be configured on the ASA. If this parameter is omitted, the sequence value is 0, and the 
order of the ACEs inside the cisco-av-pair RADIUS VSA is used.
The following example is an ACL definition as it should be configured for a cisco-av-pair VSA on a 
RADIUS server:
ip:inacl#1=permit tcp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
ip:inacl#99=deny tcp any any
ip:inacl#2=permit udp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
ip:inacl#100=deny udp any any
ip:inacl#3=permit icmp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
For information about making unique per user the ACLs that are sent in the cisco-av-pair attribute, see 
the documentation for your RADIUS server.
On the ASA, the downloaded ACL name has the following format:
AAA-user-username 
						

							 
8-17
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Accounting for Network Access
The username argument is the name of the user that is being authenticated.
The downloaded ACL on the ASA consists of the following lines. Notice the order based on the numbers 
identified on the RADIUS server.
access-list AAA-user-bcham34-79AD4A08 permit tcp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list AAA-user-bcham34-79AD4A08 permit udp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list AAA-user-bcham34-79AD4A08 permit icmp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list AAA-user-bcham34-79AD4A08 deny tcp any any
access-list AAA-user-bcham34-79AD4A08 deny udp any any
Downloaded ACLs have two spaces between the word “access-list” and the name. These spaces serve to 
differentiate a downloaded ACL from a local ACL. In this example, “79AD4A08” is a hash value 
generated by the ASA to help determine when ACL definitions have changed on the RADIUS server.
Converting Wildcard Netmask Expressions in Downloadable ACLs
If a RADIUS server provides downloadable ACLs to Cisco VPN 3000 series concentrators as well as to 
the ASA, you may need the ASA to convert wildcard netmask expressions to standard netmask 
expressions. This is because Cisco VPN 3000 series concentrators support wildcard netmask 
expressions, but the ASA only supports standard netmask expressions. Configuring the ASA to convert 
wildcard netmask expressions helps minimize the effects of these differences on how you configure 
downloadable ACLs on your RADIUS servers. Translation of wildcard netmask expressions means that 
downloadable ACLs written for Cisco VPN 3000 series concentrators can be used by the ASA without 
altering the configuration of the downloadable ACLs on the RADIUS server.
You configure ACL netmask conversion on a per-server basis when you add a server to a server group 
in the Configuration > Device Management > Users/AAA > AAA Server Groups > AAA Server Groups 
area.
Configuring a RADIUS Server to Download Per-User Access Control List Names
To download a name for an ACL that you already created on the ASA from the RADIUS server when a 
user authenticates, configure the IETF RADIUS filter-id attribute (attribute number 11) as follows:
filter-id=acl_name
NoteIn Cisco Secure ACS, the values for filter-id attributes are specified in boxes in the HTML interface, 
omitting filter-id= and entering only acl_name.
For information about making the filter-id attribute value unique per user, see the documentation for your 
RADIUS server.
To create an ACL on the ASA, see Chapter 21, “Using the ACL Manager,” in the general operations 
configuration guide.
Configuring Accounting for Network Access
The ASA can send accounting information to a RADIUS or TACACS+ server about any TCP or UDP 
traffic that passes through the ASA. If that traffic is also authenticated, then the AAA server can maintain 
accounting information by username. If the traffic is not authenticated, the AAA server can maintain  
						

							 
8-18
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Configuring Accounting for Network Access
accounting information by IP address. Accounting information includes session start and stop times, 
username, the number of bytes that pass through the ASA for the session, the service used, and the 
duration of each session.
To configure accounting, perform the following steps:
Step 1If you want the ASA to provide accounting data per user, you must enable authentication. For more 
information, see the “Configuring Network Access Authentication” section on page 8-6. If you want the 
ASA to provide accounting data per IP address, enabling authentication is not necessary and you can 
continue to the next step.
Step 2In the Configuration > Firewall > AAA Rules pane, choose Add > Add Accounting Rule.
The Add Accounting Rule dialog box appears.
Step 3In the Interface drop-down list, choose the interface for applying the rule.
Step 4In the Action field, click one of the following, depending on the implementation:
Account 
Do not Account
Step 5In the AAA Server Group drop-down list, choose a server group. To add a AAA server to the server 
group, click Add Server.
Step 6In the Source field, enter the source IP address, or click the ellipsis (...) to choose an IP address already 
defined in ASDM.
Step 7In the Destination field, enter the destination IP address, or click the ellipsis (...) to choose an IP address 
already defined in ASDM.
Step 8In the Service field, enter an IP service name or number for the destination service, or click the ellipsis 
(...) to choose a service.
Step 9(Optional) In the Description field, enter a description.
Step 10(Optional) Click More Options to do any of the following:
To specify a source service for TCP or UDP, enter a TCP or UDP service in the Source Service field.
The destination service and source service must be the same. Copy and paste the Destination Service 
field content to the Source Service field.
To make the rule inactive, clear the Enable Rule check box.
You may not want to remove a rule, but instead turn it off.
To set a time range for the rule, In the Time Range drop-down list, choose an existing time range. 
To add a new time range, click the ellipsis (...). For more information, see the “Configuring Time 
Ranges” section on page 20-26 in the general operations configuration guide.
Step 11Click OK.
The Add Accounting Rule dialog box closes and the rule appears in the AAA Rules table.
Step 12Click Apply.
The changes are saved to the running configuration.
AAA provides an extra level of protection and control for user access than using ACLs alone. For 
example, you can create an ACL allowing all outside users to access Telnet on a server on the DMZ 
network. If you want only some users to access the server and you might not always know IP addresses  
						

							 
8-19
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Using MAC Addresses to Exempt Traffic from Authentication and Authorization
of these users, you can enable AAA to allow only authenticated and/or authorized users to connect 
through the ASA. (The Telnet server enforces authentication, too; the ASA prevents unauthorized users 
from attempting to access the server.)
Using MAC Addresses to Exempt Traffic from Authentication 
and Authorization
The ASA can exempt from authentication and authorization any traffic from specific MAC addresses.
For example, if the ASA authenticates TCP traffic originating on a particular network but you want to 
allow unauthenticated TCP connections from a specific server, you would use a MAC exempt rule to 
exempt from authentication and authorization any traffic from the server specified by the rule. This 
feature is particularly useful to exempt devices such as IP phones that cannot respond to authentication 
prompts.
The order of entries matters, because the packet uses the first entry it matches, instead of a best match 
scenario. If you have a permit entry, and you want to deny an address that is allowed by the permit entry, 
be sure to enter the deny entry before the permit entry.
To use MAC addresses to exempt traffic from authentication and authorization, perform the following 
steps:
Step 1In the Configuration > Firewall > AAA Rules pane, choose Add > Add MAC Exempt Rule.
The Add MAC Exempt Rule dialog box appears.
Step 2In the Action drop-down list, click one of the following options, depending on the implementation:
MAC Exempt
No MAC Exempt
The MAC Exempt option allows traffic from the MAC address without having to authenticate or 
authorize. The No MAC Exempt option specifies a MAC address that is not exempt from authentication 
or authorization. You might need to add a deny entry if you permit a range of MAC addresses using a 
MAC address mask such as ffff.ffff.0000, and you want to force a MAC address in that range to be 
authenticated and authorized.
Step 3In the MAC Address field, specify the source MAC address in 12-digit hexadecimal form; that is, 
nnnn.nnnn.nnnn.
Step 4In the MAC Mask field, specify the portion of the MAC address that should be used for matching. For 
example, ffff.ffff.ffff matches the MAC address exactly. ffff.ffff.0000 matches only the first 8 digits.
Step 5Click OK.
The Add MAC Exempt Rule dialog box closes and the rule appears in the AAA Rules table.
Step 6Click Apply.
The changes are saved to the running configuration. 
						

							 
8-20
Cisco ASA Series Firewall ASDM Configuration Guide
 
Chapter 8      Configuring AAA Rules for Network Access
  Feature History for AAA Rules
Feature History for AAA Rules
Ta b l e 8 - 1 lists each feature change and the platform release in which it was implemented. ASDM is 
backwards-compatible with multiple platform releases, so the specific ASDM release in which support 
was added is not listed.
Table 8-1 Feature History for AAA Rules
Feature NamePlatform 
Releases Feature Information
AAA Rules 7.0(1) AAA Rules describe how to enable AAA for network 
access.
We introduced the following screens:
Configuration > Firewall > AAA Rules
Configuration > Firewall > Advanced > Virtual Access.
Authentication using Cut-Through Proxy 9.0(1) You can authenticate using AAA rules in conjunction with 
the Identity Firewall feature.