Configuring AAA For Cut-Through Proxy

Configuring AAA for Cut-Through Proxy
Created by Bob Eckhoff
Introduction to AAA
This topic introduces the concepts of Authentication, Authorization, and Accounting (AAA) and how Cisco security appliances support them.
Authentication, Authorization, and Accounting

Web Server Cisco Secure ACS Server
Internet
Authentication Who you are Authorization What you can do Accounting What you did
2008 Cisco Systems, Inc. All rights reserved.
AAA is used to tell the security appliance who the user is (authentication), what the user can do (authorization), and what the user did (accounting). Authentication is valid without authorization. Authorization is never valid without authentication. Suppose you have 100 users and you want only 6 of these users to be able to use FTP, Telnet, HTTP, or HTTPS to access internal network resources from the outside. Configure the security appliance to authenticate inbound traffic from the outside and give each of the six users an identification on the AAA server. With simple authentication, these six users are authenticated with a username and password and then permitted access to the internal network. The other 94 users cannot access the internal network. The security appliance prompts users for their username and password, and then passes their username and password to the AAA server. Depending on the response, the security appliance permits or denies the connection. Suppose you want to allow one of these users, BADUSER, to use only HTTP, but not Telnet, to connect to the internal network resources. This means you must add authorizationin addition to authenticating who the users are, you must authorize what they can do. When you add authorization to the security appliance, it first sends the username and password to the AAA server, then sends an authorization request telling the AAA server which command BADUSER is trying to use. With the server set up properly, BADUSER is allowed to use HTTP but is not allowed to use Telnet.
2008 Cisco Systems, Inc.
Types of Authentication
Access to the security appliance Access through the security appliance Cut-through proxy VPN tunnel access
Security Appliance Console Access Internet Authentication Security Appliance Console Access
Web Server Cut-Through Proxy Internet Authentication VPN tunnel
There are three types of authentication: security appliance access, cut-through proxy, and tunnel access. Security appliance access enables you to require authentication verification to access the security appliance. In the example in the figure, a remote administrator is attempting to access the security appliance via Secure Shell (SSH) protocol from the home office of the user while a local administrator is attempting to access the security appliance via Telnet. Both users must be authenticated before they are permitted to access the security appliance. For cut-through proxy authentication, which is the focus of this lesson, the security appliance can be configured to require user authentication for a session through the security appliance, as specified in the aaa authentication command. A user at a given IP address only needs to authenticate one time, until the authentication session expires. For example, if you configure the security appliance to authenticate Telnet and FTP, and a user first successfully authenticates for Telnet, as long as the authentication session exists, the user does not also have to authenticate for FTP. The security appliance can be configured to directly authenticate HTTP, HTTPS, Telnet, and FTP cut-through sessions. In the example in the figure, a remote user is attempting an HTTP session with the web server. If the user is authenticated by the security appliance, the HTTP session to the web server is connected via cut-through proxy authentication. Once the security appliance successfully authenticates the user, the security appliance then shifts the session flow, and all traffic flows directly between the server and the client while the security appliance maintains the session state information. For VPN tunnel access authentication, the security appliance can be configured to require a remote tunnel user to authenticate before complete tunnel establishment. In the example in the figure, a remote user establishes a VPN tunnel with the corporate office to gain access to the corporate web server. Before the tunnel is fully established, the security appliance will prompt the remote user for a username and password. The credentials are verified before the remote user tunnel is fully established and the remote user is allowed to access the corporate web server.
Types of Authorization
Console access: Specifies whether command execution is subject to authorization Cut-through proxy: Specifies what through services are subject to authorization Tunnel access: Specifies what tunnel services are authorized
Security Appliance Console Access Internet Authentication Security Appliance Console Access
Web Server Cut-Through Proxy Internet Authentication IPsec and SSL VPN
There are also three types of authorization: security appliance console access, cut-through proxy, and tunnel access. Security appliance access authorization is a way of facilitating and controlling administration access (such as serial, SSH, and Telnet access), including who can access the security appliance and which commands they can execute. The administrator assigns commands to a privilege level. The administrator creates user accounts and links a privilege level to each user. When console users attempt to access the security appliance console, they are prompted for a username and password. When authenticated, console users are granted the access level privileges that are assigned to their respective user accounts. If the administrator wants to allow all authenticated users to perform all HTTP, HTTPS, FTP, and Telnet operations through the security appliance, authentication is sufficient and authorization is not needed. However, if there is reason to allow only some subset of users, or to limit users to certain sites and protocols, authorization is needed. The security appliance supports two basic methods of user authorization of cut-through proxy, which is the focus of this lesson: The security appliance is configured with rules specifying which connections need to be authorized by the AAA server. When the first packet of a traffic flow matches a predefined rule, the AAA server is consulted by the security appliance for access rights. The AAA server returns a permit or deny authorization message. The security appliance is configured with rules that specify which connections need to be authenticated by the AAA server. The AAA server is configured with authorization rules that are assigned to the authenticating user. The authorization rules come in the form of access control lists (ACLs). An ACL is attached to the user or group profile on the AAA server. When the first packet of a traffic flow matches a predefined rule, the AAA server is consulted by the security appliance for access rights, permit or deny. During the authentication process, if the end user is authenticated, the Cisco Secure Access Control Server (ACS) downloads an ACL to the security appliance. The ACL is applied to the traffic flow. The Cisco Secure ACS has the ability to store ACLs and download them to the security appliance.
When remote users attempt to establish a tunnel to the security appliance, the administrator can force the tunnel users to authenticate before granting them access to the security appliance. When a tunnel user authenticates, the security appliance retrieves tunnel information for the defined user or group. The tunnel authorization information can include such information as virtual private network (VPN) access hours, simultaneous logins, client block rules, personal computer firewall type, idle timeout, and so on. The tunnel group information is applied to the tunnel before the tunnel is fully established.
Types of Accounting
Security appliance console access Access through the security appliance Cut-through proxy Tunnel connections IPsec SSL VPN
IPsec and SSL VPN Cut-Through Proxy Internet Authentication Security Appliance Console Access Internet Authentication Security Appliance Console Access
Web Server
An administrator can configure the security appliance to enable accounting for specific network services. Accounting records are generated to track the initiation and termination of predefined sessions. The security appliance can be configured to generate accounting records for configuration changes. For example, accounting records can track when a Telnet user logged in to the security appliance, at what privilege level, what configuration commands were entered, and when the session was terminated. It can track the beginning and end of a web session between a remote user and the corporate demilitarized zone (DMZ) web server. It can also be used to track remote tunnel access, when it started and finished. These records are kept on the designated AAA server or servers.
Configuring the Local User Database

This topic explains how to configure local user accounts on the Cisco ASA security appliance.
Adding Users to the Local Database

Configuration
Users/AAA User Accounts
Authentication via Local Database

Add
Device Management
You can configure a local database in the Cisco ASA security appliance if you are not using an external AAA server, such as an ACS server, or if you want to use the local database in the Cisco ASA security appliance as a backup if the AAA server is down. You can create user accounts with passwords in the Cisco ASA security appliance local database, or you can create user accounts with no password. You can use the local database for CLI access authentication, privileged mode authentication, command authorization, network access authentication, and VPN authentication and authorization. You cannot use the local database for network access authorization. The local database does not support accounting. To create user accounts in the local database, complete the following steps:
Step 1 Step 2 Step 3 Step 4
Click Configuration in the ASDM toolbar. Choose Device Management from the navigation pane. Expand the Users/AAA menu. Choose User Accounts. The User Accounts panel is displayed. From this panel, you can access the Add User Account window to add a user account; however, you can also change the enable password from this panel by changing the password for the enable_15 user. The enable_15 user is always present in this panel and represents the default username. Click Add. The Add User Account window opens.
Step 5
Adding Users to the Local Database (Cont.)

Add User Account
Username Password Confirm Password
Step 6
Enter the username for the account in Username field. In the figure, the username admin1 is entered. Enter a password in the Password field. The minimum password length is 4 characters, and the maximum is 32 characters. A password length of at least 8 characters is recommended. Passwords are case-sensitive. When you enter a password, the Password field displays only asterisks. In the figure, the password cisco123 is entered. Enter the password again in the Confirm Password field. When you enter a password, the Confirm Password field displays only asterisks. In the figure, the password cisco123 is entered. Click OK. Click Apply in the User Accounts panel.
Step 7
Step 8
Step 9 Step 10
You can use the Edit User Account window to change the password for a user account. To access this window, select the account in the User Accounts panel and click Edit.
Note The default privilege level is 2.
Configuring Local User Lockout

Web server
172.16.1.10 Static: 192.168.1.11
http://192.168.1.11 Internet
User Name: kenny Password: password1 User Name: kenny Password: password2 User Name: kenny Password: password3 Error:Authentication Rejected Edit LOCAL Server Group
Authentication via Local Database
Enable Local User Lockout Maximum Attempts

2008 Cisco Systems, Inc. All rights reserved. 11
You can configure a maximum failed attempts value for local database users. After a user meets the configured maximum number of failed authentication attempts, the user is locked out. An administrator must clear the lockout condition before the user can successfully log in. To configure local user lockout, complete the following steps:
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8
Click Configuration in the ASDM toolbar. (not shown) Choose Device Management from the navigation pane. Expand the Users/AAA menu. Choose AAA Server Groups. From the AAA Server Groups table, select LOCAL. Click Edit. The Edit Local Server Group window opens. Check the Enable Local User Lockout check box. In the Maximum Attempts field, specify the maximum number of failed login attempts allowed before locking out and denying access to a user. You can enter a value from 1 to 16. This limit applies only when the LOCAL database is used for authentication. Click OK. Click Apply in the AAA Server Groups panel.
Step 9 Step 10
Displaying Locked Out Users

Monitoring Device Access AAA Local Locked Out Users
Clear Selected Lockout Properties Refresh Clear All Lockouts
12
To clear lockout conditions, complete the following steps:

Click the Monitoring button in the ASDM toolbar. Choose Properties from the navigation pane. Expand the Device Access menu. Choose AAA Local Locked Out Users. The AAA Local Locked Out Users panel is displayed. This panel enables you to view a list of users who have been locked out because of failed login attempts. In the figure, user kenny is locked out. The panel shows the amount of time that the user has been locked out of the system and the number of failed login attempts for each locked out user. Select the user whose lockout condition you want to clear. Click the Clear Selected Lockout button.
Step 15 Step 16
Cisco Secure ACS Network Configuration
15
An administrator can add users to a Cisco Secure ACS server database. For the Cisco Secure ACS to communicate with the security appliance, an administrator must configure the AAA client information. The AAA client is the security appliance. Complete the following steps to add the security appliance to the Cisco Secure ACS AAA client database in your Windows 2000 server:
Step 1
The Cisco Secure ACS interface should now be displayed in your web browser. Click Network Configuration to open the Network Configuration window. Click the Add Entry button beneath the AAA Clients group box. The Add AAA Client window opens. In the AAA Client Hostname field, enter the hostname of the security appliance. In the AAA Client IP Address field, enter the IP address of the security appliance. In the Shared Secret field, enter the shared secret that the security appliance and the Cisco Secure ACS will use to encrypt the data. From the Authenticate Using drop-down menu, select an authentication protocol. Click Submit + Apply to submit the changes.
The AAA server is the Cisco Secure ACS.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Note
10
Adding Users to Cisco Secure ACS
16
The administrator can add users to the AAA server local database. To add a basic user account to the Cisco Secure ACS, complete the following steps:
Step 1
Choose User Setup from the navigation bar. The User Setup panel is displayed. Enter a name in the User field. Click Add/Edit. The Edit window opens. The username that is being added or edited appears at the top of the window. Ensure that the Account Disabled check box is unchecked. In the User Setup table, choose the applicable authentication type from the Password Authentication drop-down list. The authentication types that are displayed in the drop-down list reflect the databases that you have configured in the Database Configuration area of the External User Databases section. If you are using the local database on the ACS server, select the ACS Internal Database option from the drop-down list. Enter an ACS Password Authentication Protocol (PAP) password for the user in the first Password field. The password can be up to 32 characters. The ACS PAP password is also used for CHAP/MS-CHAP/ARAP if you do not check the Separate CHAP/MS-CHAP/ARAP check box. Enter the password again in the Confirm Password field. Click Submit to establish the user account.
Step 2 Step 3
Step 4 Step 5
Step 6
Step 7 Step 8
11
Cut-Through Proxy Authentication Configuration

This topic discusses how to configure cut-through proxy authentication on Cisco security appliances.
Cut-Through Proxy Operation

Types of cut-through proxy user authentication: Telnet HTTP Web FTP HTTPS Server 5 The local username and
The user makes a request to access the web server.
1
password are passed to the web server to authenticate.

5 3 4
Internet
2
The user is prompted by the security appliance.

3
Cisco Secure ACS
Bill Smith cisco123
The security appliance queries Cisco Secure ACS for the remote username and password. If Cisco Secure ACS authenticates, the user is cut through the security appliance.
18
The security appliance gains dramatic performance advantages because of cut-through proxy: a method of transparently verifying the identity of users at the security appliance and permitting or denying network access. This method eliminates the price and performance impact that UNIX system-based firewalls impose in similar configurations, and it leverages the authentication and authorization services of the Cisco Secure ACS. The security appliance cut-through proxy challenges a user initially at the application layer, and then authenticates against a standard AAA server or the local database. After the policy is checked, the security appliance shifts the session flow, and all traffic flows directly and quickly between the server and the client while maintaining session state information. To authenticate a cut-through proxy user, only FTP, Telnet, HTTP, and HTTPS sessions can be intercepted. For these sessions, the security appliance generates an authentication prompt (Telnet and FTP) or can redirect you to an internal web page where you can enter your username and password (HTTP and HTTPS). After you authenticate correctly, the security appliance redirects you to your original destination. If the destination server also has its own authentication, you must enter another username and password. Keep in mind that browsers cache usernames and passwords. If you believe that the security appliance should be timing out an HTTP or HTTPS connection but it is not, reauthentication may actually be taking place, with the web browser sending the cached username and password back to the security appliance. If Telnet and FTP seem to work normally, but HTTP and HTTPS connections do not, this reason is usually why.
12
The authentication ports that the security appliance supports for AAA are fixed as follows: Port 21 for FTP Port 23 for Telnet Port 80 for HTTP Port 443 for HTTPS
13
Company XYZ Need: Authentication for Access to Resources
Branch Office
Internet
FTP
ftp> get example.doc

Corporate DMZ
Web
Headquarters
ACS
Users at the Company XYZ branch office often need access to files on the FTP server that resides on the Corporate DMZ. These users also need access to the web server on the corporate DMZ. Access lists are in place on the corporate security appliance to allow this access. These access lists only permit branch office users to access the DMZ servers and prevent other users from accessing the DMZ servers. The network security administrator for Company XYZ would like to implement an additional layer of security by requiring users to supply usernames and passwords before being allowed to access the DMZ servers.
14
Cut-Through Proxy User Authentication: Configuration Tasks
Branch Office
Internet
Specify a AAA server group Designate an authentication server Enable cut-through proxy user authentication
FTP
ftp> get example.doc

Corporate DMZ
Web
Headquarters
ACS
20
To require users to authenticate before accessing the corporate DMZ servers, the network security administrator needs to configure cut-through proxy authentication, using the following three-step process:
Step 1
Specify an AAA server group by defining a group name and the authentication protocol. Designate an authentication server by defining the location of the AAA server and a key. Enable cut-through proxy user authentication by configuring a rule that specifies which traffic flow to authenticate.
Step 2
Step 3
15
Specifying a AAA Server Group

Configuration Add
Users/AAA
AAA Server Groups
Device Management
21
Use the AAA Server Groups panel to specify AAA server groups. For security appliance access authentication, the security appliance supports TACACS+, RADIUS, Windows NT, Kerberos, Lightweight Directory Access Protocol (LDAP), RSA SecurID, and local database authentication. The security appliance enables you to define separate groups of AAA servers for specifying different types of traffic, such as a TACACS+ server for inbound traffic and another for outbound traffic. You can have up to 15 single-mode server groups, and each group can have up to 16 AAA servers, for a total of up to 240 AAA servers. You can have up to four server groups per context in multiple mode, and each group can have up to four AAA servers. When a user logs in, the servers are accessed one at a time, starting with the first server in the server group configuration, until a server responds. To specify an AAA server group, complete the following steps:
Click Configuration in the ASDM toolbar. Choose Device Management from the navigation pane. Expand the Users/AAA menu. Choose AAA Server Groups. The AAA Server Groups panel is displayed. The fields in the AAA Server Groups panel are grouped into two main areas: the AAA Server Groups area and the Servers In The Selected Group area. The AAA Server Groups area enables you to configure AAA server groups and specify the protocols that the security appliance uses to communicate with the servers listed in each group. The Servers in the Selected Group area enables you to add individual servers to AAA server groups. Click Add in the AAA Server Groups area. The Add AAA Server Group window opens.
Step 5
16
Adding a AAA Server Group

Corporate DMZ
Web FTP
Headquarters
Internet Branch Office user
RADIUS
AUTHIN Authentication Server
Add AAA Server Group Server Group Protocol Accounting Mode Reactivation Mode Dead Time Max Failed Attempts
22
Step 6
Enter a name for the server group in the Server Group field. In the figure, the name AUTHIN is entered. Choose the AAA protocol that servers in the group support from the Protocol drop-down list. You can choose RADIUS, TACACS+, NT Domain, SDI, Kerberos, LDAP, or HTTP Form. In the figure, RADIUS is chosen.
HTTP Form is for Clientless SSL VPN users only. If you choose HTTP Form, the Accounting Mode radio buttons are not available.
Step 7
Note
Step 8
Specify the accounting mode to be used with the server group by choosing one of the Accounting Mode radio buttons. If you choose the Simultaneous button, the security appliance sends accounting data to all servers in the group. If you choose the Single button, the security appliance sends accounting data to only one server. In the figure, the Single radio button is chosen. In the figure, the default setting of Single is used. Specify the method by which failed servers are reactivated by choosing one of the Reactivation Mode radio buttons. If you choose the Depletion button, failed servers are reactivated only after all of the servers in the group are inactive. If you choose the Timed radio button, failed servers are reactivated after 30 seconds of down time. In the figure, the default setting of Depletion is used. In the Dead Time field, enter the number of minutes you want to elapse between the disabling of the last server in the group and the subsequent reenabling of all servers. This parameter applies only if you specify Depletion for the Reactivation mode. In the figure, the default setting of 10 is used.
Step 9
Step 10
17
Step 11
In the Max Failed Attempts field, enter the number of failed connection attempts allowed before declaring a non=responsive server inactive. You can specify 1 through 5 attempts. In the figure, the default setting of 3 is used. Click OK. Click Apply in the AAA Server Groups panel.
Step 12 Step 13
18
Designating an Authentication Server: RADIUS Corporate

Web
DMZ
FTP
Headquarters
RADIUS
10.0.1.2
AUTHIN Authentication Server
Add AAA Server Server Group Interface Name Server Name or IP Address Timeout
RADIUS Parameters Server Authentication Port Server Accounting Port Retry Interval Server Secret Key
23
The next task is to define the AAA server and the AAA server attributes by completing the following steps:
Step 1
Select a configured server group from the AAA Server Groups table in the AAA Server Groups panel. In the figure, the Server Group label shows that the AUTHIN group was selected. Click Add in the Servers in Selected Group area of the AAA Server Groups panel. The Add AAA Server window opens. From the Interface Name drop-down list, choose the interface where the AAA server resides. In the figure, the inside interface is chosen. Enter the name or IP address of the AAA server in the Server Name or IP Address field. In the figure, 10.0.1.2 is entered. In the Timeout field, specify the timeout interval, in seconds. This interval is the time after which the security appliance gives up an authentication request to the primary AAA server. If a standby AAA server is designated, the security appliance sends the request to the backup server after the timeout interval has elapsed. In the figure, the default value of 10 seconds is accepted. In the Server Authentication Port field within the RADIUS Parameters area, specify the server port to use for user authentication. The default port is 1645. The latest RADIUS RFC states that RADIUS should use UDP port number 1812, so you might need to change this default value to 1812. In the figure, port 1812 is specified. In the Server Accounting Port field, specify the server port to use for user accounting. The default port is 1646. The latest RADIUS RFC specifies UDP port number 1813 for RADIUS accounting, so you might need to change this default value to 1813. In the figure, port 1813 is specified.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
19
Step 8
From the Retry Interval drop-down list, choose the number of seconds that the security appliance should wait after sending a query to the server and receiving no response, before reattempting the connection. The minimum time is 1 second, and the maximum time is 10 seconds. In the figure, the default time of 10 seconds is accepted.
The RADIUS Parameters area is displayed only when the selected server group uses RADIUS.
Note
Step 9
Enter an alphanumeric value up to 64 characters in the Server Secret Key field. The server secret key is used for encrypting data between the security appliance and the RADIUS (ACS) server. The key must be the same on both the security appliance and the RADIUS (ACS) server. The key value is a case-sensitive. The Server Secret Key field displays only asterisks. In the figure, the secret key "secretkey" is entered, but only asterisks are displayed.
The Common Password and ACL Netmask Convert fields apply to RADIUS authorization, which is covered later in this lesson. Do not provide a common password when defining a RADIUS server to be used for authentication.
Note
Step 10 Step 11
Click OK. Click Apply in the AAA Server Groups panel.
20
Designating an Authentication Server: TACACS+

Web
Corporate DMZ
FTP
Headquarters
TACACS+
AUTHOUT Authentication 10.0.1.3 Server
Add AAA Server Server Group Interface Name Server Name or IP Address Timeout
TACACS+ Parameters Server Port Server Secret Key

24
The figure shows the appearance of the Add AAA Server window when a server is being added to a server group that uses the TACACS+ protocol. The Server Group label shows that the AUTHOUT server group, which uses TACACS+, was selected from the AAA Server Groups table. The first three fields in this window (Interface Name, Server Name or IP Address, and Timeout) are the same for all types of servers. The remaining fields are specific to each server type. For example, in the TACACS+ Parameters area, you can configure the following parameters that are needed for using a TACACS+ server: Server Port: The port that the AAA server will use. You can specify a port number in the range 0 through 65535. The default server port for TACACS+ is TCP port 49. Server Secret Key: A case-sensitive, alphanumeric value up to 128 characters in length. The key cannot contain spaces, but other special characters are allowed. The server secret key is used for encrypting data between the security appliance and the TACACS+ server. It must be the same on both the security appliance and the TACACS+ server.
21
Testing a AAA Server
AAA Server Groups
AAA Server Group Host Authentication Username Password
Test
25
The Test functionality in the AAA Server Groups panel can help you determine whether AAA failures are due to connection problems between the security appliance and the AAA server, misconfiguration of AAA server parameters, or other configuration errors on the security appliance. To verify that the security appliance can authenticate users with a particular AAA server, complete the following steps:
Step 1
From the AAA Server Groups table, select the group to which the server belongs. From the Servers in the Selected Group table, select the server that you want to test. Click Test. The Test AAA Server window opens. Verify that the name of the server group to which the server belongs is displayed to the right of the AAA Server Group label. Verify that the name or IP address of the server is displayed to the right of the Host label. Choose the Authentication radio button, which specifies that ASDM tests authenticating a user with the selected AAA server. If the server type selected does not support authentication, this radio button is not available. For example, the security appliance does not support authentication with LDAP servers. The Authorization button is for testing legacy VPN authorization. In the Username field, enter the username that you want to use to test the AAA server. Make sure the username exists on the AAA server; otherwise, the test will fail.
Step 2
Step 3 Step 4
Step 5
Step 6
Step 7
22
Step 8
In the Password field, enter the password for the username that you entered in the Username field. The Password field is available only for authentication tests. Make sure that the password is correct for the username entered; otherwise, the authentication test will fail. Click OK. The security appliance sends the applicable test message to the selected server. If the test fails, ASDM displays an error message about the type of error encountered.
Test AAA Server is not available for HTTP Form authentication servers.
Step 9
Note
23
Enabling Cut-through Proxy User Authentication

Configuration
AAA Rules Add
Firewall Advanced
26
The final task for configuring cut-through proxy authentication is configuring a rule that specifies which traffic flow to authenticate. Complete the following steps to configure an authentication rule:
Step 1 Step 2 Step 3
Click Configuration in the ASDM toolbar. Choose Firewall from the navigation pane. Choose AAA Rules from the Firewall menu. The AAA Rules panel is displayed. Click Add. Choose Add Authentication Rule from the drop-down list. The Add Authentication Rule window opens.
Step 4 Step 5
24
Enabling Cut-through Proxy User Authentication (Cont.)

FTP Server
Internet
192.168.1.11 (FTP) 192.168.1.12 (Web)
Web Server
RADIUS
Authentication Add Authentication Rule Interface Action AAA Server Group Source Destination Service Enable Rule
AUTHIN Server 10.0.1.2
27
Step 6
From the Interface drop-down list, choose the interface to which you want to apply the rule. In the figure, the outside interface is chosen. Verify that the Authenticate radio button is selected. The Do Not Authenticate option is used for excluding addresses from authentication. For example, if you want to require authentication for all hosts on the 10.0.1.0/24 network except host 10.0.1.50, you would create two rules, one using the Authenticate option and the other using the Do Not Authenticate option. If you configure an exclusion, be sure to order the rules appropriately. For example, in this instance, you would place the Do Not Authenticate rule above the Authenticate rule so that traffic from host 10.0.1.50 matches the Do Not Authenticate rule first. From the AAA Server Group drop-down list, choose a server group or the local user database. If you choose a server group, the button to the right of the drop-down list is labeled "Add Server." Clicking this button opens an Add AAA Server window where you can add a new server to the selected server group. If you choose LOCAL from the drop-down list, the button to the right of the drop-down list becomes the "Add User" button. Clicking this button opens an Add User Account window where you can add a new user to the local user database. In the figure, the server group AUTHIN is chosen from the AAA Server Group drop-down list. In the Source field, enter the source IP address or click the ... button to choose an IP address that is already defined in ASDM. Specify the address and subnet mask using slash notation, such as 10.0.1.0/24. If you enter an IP address without a mask, it is considered a host address, even if it ends with a 0. Enter the word "any" to specify any source address. If you enter multiple addresses, separate them with a comma. In the figure, "any" is specified in the Source field.
Step 7
Step 8
Step 9
25
Step 10
In the Destination field, enter the destination IP address or click the ... button to choose an IP address that is already defined in ASDM. Specify the address and subnet mask using slash notation, such as 10.0.1.0/24. If you enter an IP address without a mask, it is considered a host address, even if it ends with a 0. Enter the word "any" to specify any destination address. If you enter multiple addresses, separate them with a comma. In the figure, 192.168.1.11, the statically-mapped IP address of host 172.16.1.10, is specified as the destination. In the Service field, enter an IP service name or number for the destination service, or click the ... button to choose a service. To specify a TCP or UDP port number or an ICMP service number, enter protocol/port, such as TCP/80. Separate multiple services with commas. Be sure to include the destination port for HTTP, HTTPS, Telnet, or FTP because users must authenticate with one of these services before other services are allowed through the security appliance. In the figure, tcp/ftp is entered in the Service field. Optionally, enter a description for the rule in the Description field. Click the More Options double arrow. Verify that the Enable Rule check box is checked. You can deactivate the rule by unchecking this check box. This action is useful if you want to temporarily deactivate the rule without removing it. In the figure, the check box is checked. Optionally, specify a source service for TCP or UDP in the Source Service field. Optionally, set a time range for the rule by choosing a time range from the Time Range drop-down list. You can also click the ... button to create a new time range. In the figure, no time range is specified. Click OK. Click Apply in the AAA Rules panel.
Step 11
Step 15
Step 16
Step 17 Step 18
In this example, after the authentication rule is applied, users are prompted for a username and password when they start FTP connections to 192.168.1.11 from the outside. The AAA server verifies whether the username and password are correct. If they are correct, the security appliance cut-through proxy permits further traffic between the initiating host and the target host.
26
Displaying Authenticated Users

Monitoring Device Access Authenticated Users
Properties
Refresh
30
The Authenticated Users panel in ASDM enables you to see which users are authenticated. In the example in the figure, user carter at host insidehost is authenticated. To display authenticated users, complete the following steps:
Click the Monitoring button in the ASDM toolbar. Choose Properties from the navigation pane. Expand the Device Access menu. Choose Authenticated Users. The Authenticated Users panel displays the username of the person authenticated to use the security appliance, along with the IP address of the authenticated user, dynamic ACLs, the amount of time that the user must remain inactive before the session times out and the user is disconnected, and the amount of time that the user can remain connected before the session closes and the user is disconnected.
You can use the clear uauth CLI command to delete all authorization caches for all users, which causes them to reauthenticate the next time they create a connection.
27
Viewing AAA Server Statistics
Monitoring AAA Servers
Clear Server Statistics Update Server Statistics
Properties
Refresh
31
To display statistics for an AAA server, choose AAA Servers from the Monitoring > Properties menu. The resulting AAA Servers panel displays a table that lists the AAA servers that you have configured plus the local database. The table contains the following information for each configured AAA server: The server group to which the server belongs The protocol that the server group uses for AAA The IP address of the AAA server The status (Active or Inactive) of the AAA server The area below the table displays the statistics for the server that you select. You can clear the statistics by clicking the Clear Server Statistics button, and you can refresh the server statistics by clicking the Refresh button. The Update Server Status button refreshes the server status.
28
Why Enable Secure Authentication of Web Clients?

HTTP server
Corporate user
Username: carter Password: carterbear Username: carter Password: carterbear
Internet
Username: carter Password: carterbear
TACACS+
ACS Attacker
10.0.1.3
HTTP Authentication:
The username and password are sent from the client to the security appliance in clear text. The username and password are also sent on to the destination web server. The security appliance provides several methods of securing HTTP authentication.
32
If you use HTTP authentication, by default the username and password pair are sent from the client to the security appliance in clear text; in addition, the username and password are sent on to the destination web server. The security appliance provides the following methods of securing HTTP authentication: Enable the exchange of usernames and passwords between a web client and the security appliance with HTTPS. Enable the redirection method of authentication for HTTP. Enable virtual HTTP.
29
Enabling HTTPS Between the Web Client and the Security Appliance
HTTPS prompt HTTPS server example.com SSL Internet SSL
Corporate user
https://example.com Username: carter Password: carterbear
TACACS+
AAA Rules Advanced Options Enable Secure HTTP
Username: ? Password: ? Attacker ACS 10.0.1.3
33
Enabling the exchange of usernames and passwords between a web client and the security appliance with HTTPS is the only method of enabling secure authentication of web clients that protects credentials between the client and the security appliance, as well as between the security appliance and the destination web server. You can use this method alone or with either of the other methods so you can maximize your security. After enabling this feature, when a user requires authentication when using HTTP, the security appliance redirects the HTTP user to an HTTPS prompt. After the user authenticates correctly, the security appliance redirects the user to the original URL. Secured web-client authentication has the following limitations: Only 16 concurrent HTTPS authentication sessions are allowed. If all 16 HTTPS authentication processes are running, a new connection that requires authentication will fail. When the authentication timeout is set to 0, HTTPS authentication might not work. If a browser initiates multiple TCP connections to load a web page after HTTPS authentication, the first connection is allowed through, but the subsequent connections trigger authentication. As a result, users are continuously presented with an authentication page, even if the correct username and password are entered each time. To work around this issue, you can set the authentication timeout to 1 second; however, this workaround opens a 1-second window of opportunity that might allow nonauthenticated users to make connections through the security appliance if they are initiating connections from the same source IP address. Because HTTPS authentication occurs on SSL port 443, you must not configure an ACL to block traffic from the HTTP client to the HTTP server on port 443. Furthermore, if static PAT is configured for web traffic on port 80, it must also be configured for the SSL port.
30
To enable the exchange of usernames and passwords between a web client and the security appliance with HTTPS, complete the following steps:
Click Configuration in the ASDM toolbar. Choose Firewall from the navigation pane. Choose AAA Rules from the Firewall menu. The AAA Rules panel is displayed. Click Advanced. The AAA Rules Advanced Options window opens. Check the Enable Secure HTTP check box. Click OK. Click Apply in the AAA Rules panel.
31
Redirecting Users to an Internal Web Page

HTTP server example.com Internet
Authentication via internal web page

http://www.example.com Username: carter Password: carterbear
Corporate user
TACACS+
Username: ? Password: ?
Attacker
Add Interactive Authentication Entry Add Protocol Interface Port Redirect Network Users for Authentication Requests
ACS 10.0.1.3
Configuration > Firewall > AAA Rules > Advanced > Add
The redirection method of securing HTTP authentication prevents the authentication credentials from continuing to the destination server. Users are redirected to an internal web page where they can enter their usernames and passwords. After the user authenticates correctly, the security appliance redirects the user to the original destination. If the destination server also requires its own authentication, the user must enter another username and password. To enable the redirection method of authentication for HTTP, complete the following steps:
Step 1
In the AAA Rules panel, click the Advanced button. The AAA Rules Advanced Options window opens. Click Add. The Add Interactive Authentication Entry window opens. Choose the HTTP radio button. To enable the redirection method of authentication for HTTPS, you will need to create a separate rule and choose the HTTPS radio button. From the Interface drop-down list, choose the interface on which you want the security appliance to listen for HTTP requests. In the figure, the inside interface is chosen. In the Port field, enter the port number on which you want the security appliance to listen or choose the port from the drop-down list. This configuration enables enable HTTP or HTTPS listening ports. By default, no listener services are enabled, and HTTP connections use basic HTTP authentication. In the figure, 80 is entered. Check the Redirect Network Users for Authentication Requests check box. If you do not check this check box, direct authentication with the security appliance is enabled, but HTTP through traffic is not redirected to the listening port for authentication. In the figure, the check box is checked. Click OK.
Step 2 Step 3
Step 4
Step 5
Step 6
Step 7
32
Step 8 Step 9
Click OK in the AAA Rules Advanced Options window. Click Apply in the AAA Rules window.
If you use basic HTTP authentication and need to enter another username and password for the destination server, you might need to configure virtual HTTP.
Note
33
Using Virtual HTTP

HTTP server example.com
Authentication with HTTP server Authentication via virtual HTTP server http://10.0.1.9 Username: carter Password: carterbear
Corporate user
Internet Username: ? Password: ?
TACACS+
ACS 10.0.1.3
Attacker
Configuration
Advanced Enable HTTP Server Virtual Access Virtual HTTP Server Display Redirection Warning Firewall
37
The virtual HTTP method of securing HTTP authentication enables you to authenticate separately with the security appliance and with the HTTP server. Even if the HTTP server does not need a second authentication, this feature is useful because it strips the basic authentication credentials from the HTTP GET request. If the destination HTTP server requires authentication in addition to the security appliance, virtual HTTP enables you to authenticate separately with the security appliance (via a AAA server) and with the HTTP server. Without virtual HTTP, the same username and password that you used to authenticate with the security appliance is sent to the HTTP server; you are not prompted separately for the HTTP server username and password. Unless the username and password pair is the same for the AAA and HTTP servers, the HTTP authentication fails. Virtual HTTP redirects all HTTP connections that require AAA authentication to the virtual HTTP server on the security appliance. The security appliance prompts for the AAA server username and password. After the AAA server authenticates the user, the security appliance redirects the HTTP connection back to the original server, but it does not include the AAA server username and password. Because the username and password are not included in the HTTP packet, the HTTP server prompts the user separately for the HTTP server username and password. For inbound connections from a lower security level interface to higher security level interface, you must include the virtual HTTP address as a destination in the ACL applied to the source interface. You must also create a static translation for the virtual HTTP IP address, even if NAT is not required. Identity NAT is typically used for this purpose. For outbound connections, there is an explicit permit for traffic; however, if you apply an ACL to an inside interface, be sure to allow access to the virtual HTTP address. A static translation is not required.
Note Do not set the authentication timeout duration to 0 seconds when using the virtual HTTP feature because this setting prevents HTTP connections to the real web server.
34
To configure virtual HTTP, complete the following steps:

Click the Configuration button in the ASDM toolbar. Choose Firewall from the navigation pane. Expand the Advanced menu. Choose Virtual Access from the Advanced menu. The Virtual Access panel is displayed. Check the Enable HTTP Server check box. Enter an IP address in the Virtual HTTP Server field. This address must be an unused address that is routed to the security appliance. In the figure, the IP address 10.0.1.9 is entered. Check the Display Redirection Warning check box if you want to notify users that the HTTP connection needs to be redirected to the security appliance. This check box is used only for text-based browsers, where the redirect cannot happen automatically. Click Apply.
Step 5 Step 6
Step 7
Step 8
35
Authenticating When Telnet, FTP, HTTP, and HTTPS Through-Traffic Is Not Permitted
Internet
ASA Virtual Authentication Session with Server
Cisco Secure ACS 10.0.1.2 Server 10.0.1.33
Users must first authenticate with HTTP, HTTPS, Telnet, or FTP before other traffic that requires authentication is allowed through the security appliance. If you do not want to allow HTTP, HTTPS, Telnet, or FTP through the security appliance but want to authenticate other types of traffic, use virtual Telnet. User telnets to a virtual telnet IP address configured on the security appliance. The security appliance provides a Telnet username and password prompt. Once authenticated, the user can successfully access other services that require authentication.
Although you can configure network access authentication for any protocol or service, you can authenticate directly with HTTP, HTTPS, Telnet, or FTP only. A user must first authenticate with one of these services before other traffic that requires authentication is allowed through. If you do not want to allow HTTP, HTTPS, Telnet, or FTP through the security appliance, but want to authenticate other types of traffic, you can use the virtual Telnet feature of the security appliance.
36
Virtual Telnet
192.168.9.10
Internet
C:\> telnet 192.168.1.9 LOGIN Authentication Username: aaauser Password: aaapass Authentication Successful
192.168.1.0
Virtual Telnet
.3 .9
Authentication
Cisco Secure ACS 10.0.1.2
File Server 10.0.1.33
Configuration Enable Telnet Server Advanced Virtual Access Virtual Telnet Server
Firewall
40
The virtual Telnet option provides a way to authenticate users who require connections through the security appliance using services or protocols that do not support authentication. When an unauthenticated user establishes a Telnet session to the virtual IP address of the security appliance, the user is challenged for the username and password, and then authenticated with the AAA server. Then the user sees the Authentication Successful message, and the authentication credentials are cached in the security appliance for the duration of the user authentication timeout. If a user wishes to log out and clear the entry in the security appliance user authentication cache, the user can again telnet to the virtual IP address. The user is challenged again for a username and password, if the username and password are correct, the security appliance removes the associated credentials from the user authentication cache, and the user receives a Logout Successful message. In the figure, the user wants to establish a Microsoft Internet Information Server (IIS) session to access the file server (10.0.1.33). The user accesses the virtual Telnet address at 192.168.1.9 and is immediately challenged for a username and password before being authenticated with the RADIUS AAA server. After the user is authenticated, the security appliance allows that user to connect to the file server without reauthentication. To configure virtual Telnet, complete the following steps:
Click the Configuration button in the ASDM toolbar. Choose Firewall from the navigation pane. Expand the Advanced menu. Choose Virtual Access from the Advanced menu. The Virtual Access panel is displayed. Check the Enable Telnet Server check box.
Step 5
37
Step 6
Enter an IP address in the Virtual Telnet Server field. This address must be an unused address that is routed to the security appliance. In the figure, the IP address 192.168.1.9 is entered. Click Apply.
Step 7
38
Authentication Prompts
Username: asjdkl Password: Username: asjfkl Password:
Define the prompts that users see when authenticating Define the messages that users get when they successfully or unsuccessfully authenticate (By default, only username and password prompts are displayed.)
43
You can configure the security appliance to display customized text to the user during the AAA authentication challenge process. You can specify the AAA challenge text for HTTP, FTP, and Telnet access through the security appliance when requiring user authentication from TACACS+ or RADIUS servers. The challenge text, or authentication prompt, appears above the username and password prompts that you view when logging in. In the figure, no authentication prompts are configured on the security appliance, so only username and password prompts are displayed.
39
How to Configure Authentication Prompts

Configuration
Users/AAA
Prompt User Accepted User Rejected
Authentication Prompt
Device Management
44
To configure authentication prompts, complete the following steps:

Step 1 Step 2 Step 3 Step 4 Step 5
Click Configuration in the ASDM toolbar. Choose Device Management from the navigation pane. Expand the Users/AAA menu. Choose Authentication Prompt. The Authentication Prompt panel is shown. In the Prompt field, enter a string of up to 235 alphanumeric characters or 31 words. The string is limited by whichever maximum is first reached. Do not use special characters; however, spaces and punctuation characters are permitted. Entering a question mark or pressing the Enter key ends the string. If you enter a question mark, it is displayed in the string. In the figure, the text "Please authenticate" is entered. In the User Accepted field, enter a message to confirm that the user has been authenticated. If a User Accepted message is configured and the user is authenticated, the security appliance displays the User Accepted message to the user. In the figure, the text "You've been authenticated" is entered. In the User Rejected field, enter a message to indicate that authentication failed. If a User Rejected message is configured and user authentication fails, the security appliance displays the User Rejected message to the user. In the figure, the text "Authentication failed. Please try again" is entered. Click Apply.
Microsoft Internet Explorer displays only up to 37 characters in an authentication prompt; Netscape Navigator displays up to 120 characters; and Telnet and FTP display up to 235 characters in an authentication prompt.
Step 6
Step 7
Step 8
Note
40
Authentication Timeouts
Inactivity timeout Absolute timeout
Authentication timeouts set the time interval before users will be required to reauthenticate. There are two types of authentication timeouts: Inactivity: Time interval for inactive sessions (no traffic) Absolute: Time interval that starts at user login
46
You can use the Global Timeouts panel is ASDM to specify how long the user authentication cache should be kept after a user connection becomes idle. To delete all authorization caches for all users, use the clear uauth CLI command. The clear uauth CLI command requires users to reauthenticate the next time they create connections. The inactivity and absolute qualifiers cause users to reauthenticate after either a period of inactivity or an absolute duration. The inactivity timer starts after a connection becomes idle. If a user establishes a new connection before the duration of the inactivity timer, the user is not required to reauthenticate. If a user establishes a new connection after the inactivity timer expires, the user must reauthenticate. The absolute timer runs continuously but waits and prompts the user again when the user starts a new connection, an example of which is when the user clicks a link after the absolute timer has elapsed. The user is then prompted to reauthenticate. The absolute timer must be briefer than the translation timer; otherwise, a user could be prompted again after the session has already ended. The inactivity timer gives users the best Internet access because they are not regularly prompted to reauthenticate. Absolute timers provide security and manage the security appliance connections better. Being prompted to reauthenticate regularly helps users manage their use of the resources more efficiently. Also, being prompted minimizes the risk that someone will attempt to continue access for another user after the first user leaves the workstation, such as in a college computer lab. An inactivity timer and an absolute timer can operate at the same time, but you should set the absolute timer duration for a longer period than the inactivity timer. If the absolute timer is set at less than the inactivity timer, the inactivity timer is never invoked. For example, if you set the absolute timer to 10 minutes and the inactivity timer to an hour, the absolute timer prompts the user every 10 minutes, and the inactivity timer will never be started. If you set the inactivity timer to some duration, but set the absolute timer to zero, users are reauthenticated only after the inactivity time elapses. If you set both timers to zero, users have to reauthenticate on every new connection.
41 Configuring AAA for Cut-Through Proxy 2008 Cisco Systems, Inc.
How to Change the Authentication Timeouts
Configuration
Advanced Authentication Absolute Global Timeouts Authentication Inactivity
Firewall
47
Complete the following steps to change the authentication timeouts:

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
Click Configuration in the ASDM toolbar. Choose Firewall from the navigation pane. Expand the Advanced menu. Choose Global Timeouts. The Global Timeouts panel is displayed. Check the Authentication Absolute check box. Enter the absolute timeout value in the Authentication Absolute field. This duration must be briefer than the Translation Slot. If you enter 0:0:0, caching is disabled, and users are required to reauthenticate on every new connection. In the figure, the absolute value is set to 2 hours and 30 minutes. Check the Authentication Inactivity check box. Enter the inactivity timeout value in the Authentication Inactivity field. This duration must be briefer than the Translation Slot. Click Apply.
Step 7 Step 8
Step 9
42
Authorization Configuration
This topic explains how to configure the Cisco security appliances for authorization using downloadable ACLs.
Security Appliance User Authorization

172.26.26.50 172.26.26.51
Internet
192.168.1.0 .2 FTP
FTP Server 10.0.1.33 FTP Authorization Cisco Secure ACS 10.0.1.2
Two supported methods:

Classic user authorization, where a TACACS+ AAA server is configured with rules and consulted for every connection on demand Download of a per-user ACL from a RADIUS AAA server during authentication
50
If you want to allow all authenticated users to engage in all operationsHTTP, HTTPS, FTP, and Telnetthrough the security appliance, authentication is sufficient and authorization is not needed. But if there is reason to allow only some subset of users or to limit users to certain sites or services, authorization is needed. The security appliance supports two basic methods of user authorization when you specify per-user access rules in the context of AAA. These two methods are as follows: Classic user authorization: The access rules are configured on the TACACS+ AAA server and consulted on demand. With classic authorization, the security appliance is configured with rules specifying which connections need to be authorized by the AAA server. The AAA server is consulted for access rights on demand. This functionality is supported only with TACACS+ servers. This type of authorization method is not covered in this lesson. Download of per-user ACLs: With downloadable ACLs, you can store full ACLs on the AAA server and download them to the security appliance. An ACL is attached to the user or group profile on the AAA server. During the authentication process, after the user credentials are authenticated, the AAA server returns the ACL to the security appliance. The returned ACL is modified based on the source IP address of the authenticated user. This functionality is supported only with RADIUS.
43
Downloadable ACL Authorization

172.16.1.12 Static: 192.168.1.12 172.16.1.10 Static: 192.168.1.11
172.26.26.50
Web Server Internet

192.168.1.12 (Web) 192.168.1.11 (FTP)
FTP Server Authentication Download ACL Cisco Secure ACS 10.0.1.2
Downloadable ACLs:
1. Authentication request to AAA server 2. Authentication response containing ACL 3. ACL download of a per-user or per-group ACL authorization
51
Downloadable ACLs give you the ability to store ACLs on the AAA server and download them to the security appliance as a user is authenticated. The security appliance permits or denies access based on the authentication of user credentials and the downloaded ACL. Users are authorized to do only what is permitted in their individual or group ACL entries. Authentication needs to be configured on the security appliance, and an ACL needs to be attached to the user or group profile on the AAA server. The security appliance supports per-user or per-group ACL authorization.
Note Downloadable ACLs are supported with RADIUS only. They are not supported with TACACS+.
44
Downloadable ACLs
1. The HTTP request to global IP address 192.168.1.12 is intercepted by the security appliance. An authentication request is sent to the AAA server. The authentication response contains the ACL name from the AAA server. The security appliance checks to see if the user ACL is already present. A request is sent from the security appliance to the AAA server for the user ACL. The ACL is sent to the security appliance. The HTTP request is forwarded to the web server.
AAA Server 10.0.1.2
1 Internet
192.168.1.12
2. 3.
7 4 2 3 6 5
4.
5.
Web Server 172.16.1.12 192.168.1.12
6. 7.
Downloadable ACLs enable you to enter an ACL once in Cisco Secure ACS, and then load that ACL to any number of security appliances. Downloadable ACLs work with ACLs that are configured directly on the security appliance and applied to its interfaces. To pass through the security appliance, traffic must be permitted by both the interface ACL and the dynamic downloaded ACL if both are applicable. If either ACL denies the traffic, the traffic is prohibited. Downloadable ACLs are applied to the interface from which the user is prompted to authenticate. They expire when the user authentication timer expires and can be removed using the clear uauth command. As shown in the figure, the following sequence of events takes place when named downloadable ACLs are configured and a user attempts to establish a connection through the security appliance: 1. The user initiates a connection to the web server at 192.168.1.12, the global (translated address). The application connection request is intercepted by the security appliance, which then interacts with the user to obtain the username and password. 2. The security appliance builds a RADIUS request that contains the user identification and password and sends it to the AAA server. 3. The AAA server authenticates the user and retrieves from its configuration database the ACL name that is associated with the user. The AAA server then builds a RADIUS response packet that contains the ACL name and sends it to the security appliance.
45
4. The security appliance checks to see if it has already downloaded the named ACL. A downloadable ACL is not downloaded again as long as it exists on the security appliance. Furthermore, to keep ACLs synchronized between a security appliance and an AAA server, the AAA server downloads to the security appliance a version identification along with the ACL name. This practice enables the security appliance to determine whether it needs to request an updated ACL. If the named ACL is not already present, the security appliance uses the ACL name as the user identification and a null password to build a RADIUS access request. The security appliance then sends the RADIUS access request to the AAA server. 5. The AAA server retrieves from its configuration database the ACL associated with the ACL name. The AAA server then builds a RADIUS response packet containing the ACL and sends it to the security appliance. 6. The security appliance extracts the ACL and applies the dynamic ACL to the interface. The decision to forward or drop the packet is based on reviewing the interface ACLs and the dynamic ACLs. In this example, the traffic is permitted and the security appliance forwards the connection request to the application server. The user then connects and interacts with the application server. The downloaded ACL appears on the security appliance as shown this sample output. The ACL name is the name for the ACL as defined in the shared profile component (SPC), and 3d936909 is a unique version identification.
access-list #ACSACL#-IP-RADIUSAUTH-3d936909 line 1 extended permit tcp 172.26.26.0 255.255.255.0 host 192.168.1.12 eq ftp access-list #ACSACL#-IP-RADIUSAUTH-3d936909 line 2 extended permit tcp 172.26.26.0 255.255.255.0 host 192.168.1.12 eq www
46
Configuring Downloadable ACLs in Cisco Secure ACS
53
You can create a downloadable IP ACL once, give it a name, and then assign the downloadable IP ACL to users or user groups by referencing the IP ACL name. A downloadable IP ACL contains one or more sets of ACL definitions. These sets of ACL definitions are called ACL Contents. Complete the following steps on the AAA server to configure downloadable ACLs:
Step 1
Choose Interface Configuration > Advanced Options from the main Cisco Secure ACS window to enable the Downloadable ACLs option. The Interface Configuration page is displayed. Click Advanced Options. The Interface Configuration Edit page is displayed. Within the Advanced Options group box, select the following: User-Level Downloadable ACLs Group-Level Downloadable ACLs
Step 2
Step 3
Step 4 Step 5
Click Submit. Choose Shared Profile Components from the main Cisco Secure ACS window. The Shared Profile Components Select page is displayed. Select Downloadable IP ACLs from the Shared Profile Components list. The Downloadable IP ACLs panel is displayed. Click Add. Enter a name for the new IP ACL in the Name field. The name may contain up to 27 characters. It must not contain spaces or any of the following characters: hyphen (-), left bracket ([), right bracket (]), slash (/), backslash (\), quotes ("), left angle bracket (<), right angle bracket (>), and dash (-).
Step 6
Step 7 Step 8
47
Step 9
(Optional) Enter a description of the new IP ACL in the Description field. The description can be up to 1000 characters. Click Add to add an ACL content to the new IP ACL. The Downloadable IP ACL Content panel is displayed. In the Name box, enter a name for the new ACL content. This name may contain up to 27 characters. It must not contain spaces or any of the following characters: hyphen (-), left bracket ([), right bracket (]), slash (/), backslash (\), quotes ("), left angle bracket (<), right angle bracket (>), and dash (-). Enter the new ACL definition in the ACL Definitions field. The ACL definition consists of one or more security appliance access-list command statements, with each statement on a separate line. Each statement must be entered without the access-list keyword and without the acl_ID argument for the ACL. The rest of the command line must conform to the syntax and semantics rules of the security appliance access-list command. A security appliance syslog message is logged if there is an error in a downloaded access-list command. Click Submit to save the ACL content.
Step 10
Step 11
Step 12
Step 13
By default ACL content applies to all AAA clients; however, you can limit specific ACL contents to certain AAA clients by defining network access filters (NAFs) in Cisco Secure ACS and associating the NAFs with ACL contents. For further information on NAFs, see the User Guide for Cisco Secure Access Control Server 4.1 on Cisco.com.
48
Assigning the ACL to the User or Group
54
After you have configured the downloadable ACL, configure a Cisco Secure ACS user or group through User Setup or Group Setup to include the defined ACL in the user or group settings using the Downloadable ACLs field to assign the ACL to the user or group.
49
Show Downloaded ACLs

Web Server
172.26.26.50 Internet 192.168.1.12 (Web) 192.168.1.11 (FTP)
FTP Server
Authentication Download RADIUSAUTH ACL
asa1# show access-list . . . access-list #ACSACL#-IP-RADIUSAUTH-3ddb8ab6; 3 elements access-list #ACSACL#-IP-RADIUSAUTH-3ddb8ab6 line 1 extended permit tcp 172.26.26.0 255.255.255.0 host 192.168.1.12 eq www (hitcnt=5) 0x5fbc7326 access-list #ACSACL#-IP-RADIUSAUTH-3ddb8ab6 line 2 extended permit tcp 172.26.26.0 255.255.255.0 host 192.168.1.11 eq ftp (hitcnt=0) 0xb9faf575 access-list #ACSACL#-IP-RADIUSAUTH-3ddb8ab6 line 3 extended deny ip any any (hitcnt=0) 0xb8b9b4e1
After a user is authenticated, you can view the downloaded ACL using the show access-list CLI command. In the example in the figure, the user at 172.26.26.50 attempts to gain access to the web server at 192.168.1.12. After the user enters a username and password, the security appliance forwards the credentials to the Cisco Secure ACS. If the user is authenticated, the Cisco Secure ACS downloads a preconfigured ACL #ACSACL#-IP-RADIUSAUTH-3ddb8ab6 to the security appliance. The ACL name, #ACSACL#-IP-RADIUSAUTH, is the name for the ACL as defined in the SPC, and 3ddb8ab6 is a unique version identification. In this example, the user is authorized to access 192.168.1.12 using HTTP or to access 192.168.1.11 using FTP, and all other traffic will be denied.
50
Show Authentication
Web Server
172.26.26.50 Internet
FTP Server
Authentication
192.168.1.12 (Web)
Download RADIUSAUTH ACL
asa1# show uauth Current Most Seen Authenticated Users 1 1 Authen In Progress 0 1 user 'aaauser' at 172.26.26.50, authenticated access-list #ACSACL#-IP-RADIUSAUTH-3ddb8ab6 (*) absolute timeout: 0:05:00 inactivity timeout: 0:00:00
With the show uauth CLI command, you can view the authenticated end users, their IP addresses, and the matching downloaded ACL. In the example in the figure, user aaauser at IP address 172.26.26.50 was authenticated. The matching ACL that was downloaded to the security appliance was named #ACSACL#-IP-RADIUSAUTH-3ddb8ab6. To view the actual ACL, you can use the show access-list command.
51
Viewing AAA Server Statistics
Monitoring AAA Servers
Clear Server Statistics Update Server Statistics
Properties
Refresh
31
To display statistics for an AAA server, choose AAA Servers from the Monitoring > Properties menu. The resulting AAA Servers panel displays a table that lists the AAA servers that you have configured plus the local database. The table contains the following information for each configured AAA server: The server group to which the server belongs The protocol that the server group uses for AAA The IP address of the AAA server The status (Active or Inactive) of the AAA server The area below the table displays the statistics for the server that you select. You can clear the statistics by clicking the Clear Server Statistics button, and you can refresh the server statistics by clicking the Refresh button. The Update Server Status button refreshes the server status.
52
Per-User Override
Web Server
172.26.26.50 Internet http://192.168.1.12
FTP Server
Authentication Download ACL
When per-user override is configured, the security appliance allows the permit or deny ACE from the downloaded per-user ACL to override the permit or deny ACE from the existing ACL. Existing ACL: Permit tcp any any eq www (hitcnt=0) Downloaded per-user ACL: Deny tcp 172.26.26.0 255.255.255.0 host 192.168.1.12 eq www (hitcnt=1)
The per-user-override feature enables a downloaded ACL to override an existing ACL assigned to a security appliance interface. For example, if the interface ACL permits all traffic from network 10.0.0.0 but the dynamic ACL denies all traffic from 10.0.0.0, the dynamic ACL overrides the interface ACL for that user. In the example in the figure, there are two ACL elements: permit any host access to any host via HTTP and deny hosts on network 172.26.26.0 access to 192.168.1.12 via HTTP. The first ACE is an existing ACE resident in the security appliance. The second is a downloadable ACE from the authentication server. When the user authenticates, the deny ACE associated with this user is downloaded to the security appliance. The downloaded ACE overrides the existing ACE in the security appliance. The deny ACE instructs the security appliance to block the inbound HTTP session to 192.168.1.12 from any host on 172.26.26.0/24.
53
Configuring Per-User Override

Internet
ACL outside_access_in with per user override Access Rules Advanced Options
RADIUS server 10.0.1.2
Per User Override
Configuration > Firewall > Access Rules > Advanced

To configure per-user override, complete the following steps:

Click the Configuration button in the ASDM toolbar. Choose Firewall from the navigation pane. Choose Access Rules from the Firewall menu. The Access Rules panel is displayed. Click Advanced. The Access Rules Advanced Options window shown in the figure opens. Choose the interface for which you want to configure per-user override from the table. If an access rule is bound to the interface, the Per User Override column displays a check box. Check the Per User Override check box. Click OK. Click Apply in the Access Rules panel.
Step 4
Step 5
54
Example: Per-User Override

aaauser 172.26.26.50 Internet http://192.168.1.12 Web Server FTP Server Authentication
Download per-user ACL #ACSACL#-IP-NO_WWW
asa1# show uauth Current Most Seen Authenticated Users 1 1 Authen In Progress 0 1 user 'aaauser' at 172.26.26.50, authenticated access-list #ACSACL#-IP-NO_WWW-41aef3fc (*) absolute timeout: 0:05:00 inactivity timeout: 0:00:00 asa1# show access-list access-list ACLOUT line 3 extended permit tcp any host 192.168.1.12 eq www (hitcnt=2) access-list AAA-WWW line 1 extended permit tcp any host 192.168.1.12 eq www (hitcnt=4) access-list #ACSACL#-IP-NO_WWW-41aef3fc line 2 extended deny tcp 172.26.26.0 255.255.255.0 host 192.168.1.12 eq www (hitcnt=1)
You can view the per-user override feature using the show uauth and show access-list CLI commands. In the example in the figure, aaauser at 172.26.26.50 attempts to establish a session with the web server at 192.168.1.12. The first ACE is from the interface ACL that permits HTTP traffic from any outside host to 192.168.1.12.
access-list ACLOUT line 3 extended permit tcp any host 192.168.1.12 eq www (hitcnt=2)
The second ACE is from the ACL that identifies which traffic flow must be authenticated. Any World Wide Web traffic that is destined for 192.168.1.12 is authenticated.
asa1(config)# access-list AAA-WWW permit tcp any host 192.168.1.12 eq www asa1(config)# aaa authentication match AAA-WWW outside AUTHIN
The session is intercepted by the security appliance, and the remote user is forced to authenticate. The third ACE is from the downloaded ACL from the Cisco Secure ACS server. Upon successful authentication by the remote user, a per-user ACL is downloaded to the security appliance. This is the third ACE element in the example in the figure.
access-list #ACSACL#-IP-NO_WWW-41aef3fc line 2 extended deny tcp 172.26.26.0 255.255.255.0 host 192.168.1.12 eq www
This downloaded ACE denies World Wide Web access to 192.168.1.12 and overrides the existing permit statement. The remote user session is blocked. Notice that under the show uauth command in the example, aaauser was successfully authenticated. The #ACSACL#-IP-NO_WWW41aef3fc ACE was applied to the session. The #ACSACL#-IP-NO_WWW-41aef3fc ACE denies HTTP access to 192.168.1.12 from the 172.26.26.0/24 network.
55
Accounting Configuration
This topic demonstrates how to enable and configure accounting for all services, specific services, or no services.
Accounting Overview
Web Server Cisco Secure ACS
Internet
Authentication Who you are Authorization What you can do Accounting What you did
63
The security appliance can send accounting information to a RADIUS or TACACS+ server about any TCP or UDP traffic that passes through the security appliance. If that traffic is also authenticated, the AAA server can maintain accounting information by username. User accounting tracks traffic that passes through the security appliance, enabling you to have a record of user activity, including when sessions start and stop, username, the number of bytes that pass through the security appliance for the session, the service used, and the duration of each session. If the traffic is not authenticated, the AAA server can maintain accounting information by IP address. Accounting messages are sent to a single server if the AAA server group is configured for single mode. Accounting messages are sent to all servers in the group if the AAA server is configured for simultaneous mode. These accounting records are kept on the designated AAA server or servers.
56
Configuring Accounting
Traffic Flow FTP HTTP Web server 172.16.1.12 static: 192.168.1.12
Internet Accounting
Add Accounting Rule Interface Action AAA Server Group Source Destination Service Enable Rule
AUTHIN 10.0.1.2
64
If you want the security appliance to provide accounting data per user, enable authentication and then complete the following steps to configure accounting:
Step 1 Step 2 Step 3 Step 4 Step 5
Click the Configuration button in the ASDM toolbar. Choose Firewall from the navigation panel. Choose AAA Rules from the Firewall menu. Click the Add button. Choose Add Accounting Rule. The Add Accounting Rule window that is shown in the figure is displayed. From the Interface drop-down list, choose the interface to which you want to apply the accounting rule. Choose the Account radio button.
The Do Not Account radio button can be used to create an exception to the rule. For example, if you want to configure accounting for network 10.1.1.0/24, but you want to exclude 10.1.1.50 from accounting, create two rules, one using the Account option and the other using the Do not Account option. Be sure to order the rules appropriately. For this example, put the aforementioned Do not Account rule above the Account rule so that traffic from 10.1.1.50 will match the Do not Account rule first.
Step 6
Step 7
Note
Step 8
From the AAA Server Group drop-down list, choose a server group. In the figure, the AUTHIN group is chosen. Optionally, you can click the Add Server button to add a AAA server to the server group.
57
Step 9
In the Source field, enter the source IP address, or click the ... button to choose an IP address that is already defined in ASDM. Specify the address and subnet mask using slash notation, such as 10.1.1.0/24. If you enter an IP address without a mask, it is considered to be a host address, even if it ends with a 0. In the figure, "any" is entered to specify any source address. In the Destination field, enter the destination IP address, or click the ... button to choose an IP address that is already defined in ASDM. Specify the address and subnet mask using slash notation, such as 10.1.1.0/24. If you enter an IP address without a mask, it is considered to be a host address, even if it ends with a 0. Enter any to specify any destination address. In the figure, the destination address 192.168.1.12 is entered. In the Service field, enter an IP service name or number for the destination service, or click the ... button to choose a service. If you want to specify a TCP or UDP port number or an ICMP service number, enter protocol/port, such as TCP/8080. To specify multiple services, separate the services with commas. In the figure, the FTP and HTTP services are specified by entering tcp/ftp,tcp/http. Optionally, enter a description for the rule in the Description field. Click the More Options double arrow. Verify that the Enable Rule check box is checked. You can deactivate the rule by unchecking this check box. This option is useful if you want to temporarily deactivate the rule without removing it. In the figure, the check box is checked. Optionally, specify a source service for TCP or UDP in the Source Service field. The destination and source service must be the same. Copy and paste the Service field to the Source Service field. In the figure, no source service is specified. Optionally, set a time range for the rule by choosing a time range from the Time Range drop-down list. You can also click the ... button to create a new time range. In the figure, no time range is specified. Click OK. Click Apply in the AAA Rules panel.
Step 10
Step 11
Step 15
Step 16
Step 17 Step 18
58
How to View Accounting Information in Cisco Secure ACS
Stop (37A3C2)
Start (37A3C2)
66
Complete the following steps to view accounting records in Cisco Secure ACS:
Step 1
Click Reports and Activity in the navigation bar. The Reports and Activity window opens. Click the RADIUS Accounting link to display the accounting records.
Step 2
59

Configuring AAA For Cut-Through Proxy - Posted - 10!30!08

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Configuring AAA For Cut-Through Proxy - Posted - 10!30!08

Enviado por

Direitos autorais:

Formatos disponíveis

Created by Bob Eckhoff

Authentication, Authorization, and Accounting

2008 Cisco Systems, Inc. All rights reserved.