Configuring Authorization
Cisco ASA supports authorization services over TACACS+ for firewall cut-through proxy sessions. It also supports authorization services over TACACS+ and its internal user database for administrative sessions. RADIUS-downloadable ACLs are also supported by Cisco ASA. Command access is authorized by privilege level only when authorization is done against the local database.
Additionally, authorization over RADIUS, LDAP, and internal user databases is available for VPN user connections. This is used for mode-config attributes for remote-access VPN clients. Information about mode-config and its attributes is provided in Chapter 17.
Complete the following steps to configure authorization with ASDM:
- step 1. Log in to ASDM and navigate to Configuration > Firewall > AAA Rules.
- step 2. Click on Add and select Add Authorization Rule. The dialog box shown in Figure 6-10 is displayed.
Figure 6-10 Add Authorization Rule Dialog Box
- step 3. Select the interface where the authentication rule will be applied from the Interface pull-down menu. The inside interface is selected in this example.
- step 4. Select Authorize in the Action field to require user authentication.
- step 5. Select the AAA server group (my-tacacs-group) from the AAA Server Group pull-down menu.
- step 6. You must specify a source and a destination for traffic that will require authorization. Enter the source IP address, network address, or the any keyword in the Source field. Alternatively, you can click the ellipsis (...) to select an address that has already being configured in ASDM. In this example the any keyword is entered to require authentication for any source from the inside interface.
- step 7. Enter the destination IP address, network address, or the any keyword in the Destination field. Alternatively, you can click the ellipsis (...) to select an address that has already been configured in ASDM. In this example, the any keyword is entered to require authorization when a host tries to reach any destination
- step 8. Enter an IP service name for the destination service in the Service field. Alternatively, click the ellipsis (...) button to open a separate dialog box where you can select from a list of available services. In this example, authentication is required for any host trying to access any TCP-based applications.
- step 9. You can optionally enter a description for the authentication rule in the Description field.
- step 10. Click OK.
- step 11. Click Apply to apply the configuration changes.
- step 12. Click Save to save the configuration in the Cisco ASA.
)
Alternatively, in the CLI, the aaa authorization match command enables authorization for firewall cut-through proxy and administrative sessions. The following is the syntax for this command to enable authorization for firewall cut-through proxy sessions:
aaa authorization matchaccess_list_name if_name server_tag
The access_list_name option specifies the ACL name used to categorize which traffic requires authorization.
Command Authorization
You enable command authorization in ASDM by following these steps:
- step 1. Log in to ASDM and navigate to Configuration > Device Management > Users/AAA > AAA Access > Authorization.
- step 2. Click on Enable to enable authorization.
- step 3. Select the AAA server group under the Server Group pull-down menu.
- step 3. Optionally, you can select the Use LOCAL when Server Group Fails check box as a fallback method in case the TACACS+ server is unreachable.
- step 4. To perform authorization for exec shell access, click on Enable under the Perform Authorization for Exec Shell Access section. You can specify whether authorization is performed by using the remote server parameters or the local authentication server.
- step 5. Click Apply to apply the configuration changes.
- step 6. Click Save to save the configuration in the Cisco ASA.
To configure command authorization via the CLI, use the following command:
aaa authorization command {LOCAL | tacacs_server_tag [LOCAL]}
The server tag LOCAL defines local command authorization. It can also be used as a fallback method in case the TACACS+ server is unreachable.
When using authorization, the following attributes are passed to the TACACS+ server in the attribute payload of the authorization request message:
- cmd—The command string to be authorized (used for authorization for administrative sessions only)
- cmd-arg—The command arguments to be sent (used for authorization for administrative sessions only)
- service—The type of service for which authorization is requested
The following attributes may be received from a TACACS+ server in an authorization response message:
- idletime—Idle timeout value for firewall cut-through proxy sessions
- timeout—Absolute timeout value for firewall cut-through proxy sessions
- acl—The identifier of an ACL to be applied to a specific user
Configuring Downloadable ACLs
Cisco ASA provides support for a per-user ACL authorization by enabling you to download an ACL from a RADIUS or TACACS+ server. This feature allows you to push an ACL to the Cisco ASA from a CiscoSecure ACS server. The downloadable ACL works in combination with the ACLs configured in the ASA. The user traffic needs to be permitted by both ACLs for it to flow through the ASA. However, the per-user-override option can be configured at the end of the access-group command to bypass this requirement. The following is an example of applying the per-user-override option on an access-group command applied to the inside interface:
access-group 100 in interface inside per-user-override
In ASDM, configure this by navigating to Configuration > Firewall > Access Rules and clicking on the Advanced button. The Access Rules Advanced Options dialog box is displayed, enabling you to select the Per User Override option on each access list entry.
All downloadable ACLs are applied to the interface from which the user is authenticated.
Figure 6-11 and the steps following illustrate an example of how downloadable ACLs work.
)
Figure 6-11 Downloadable ACL Example
- step 1. A user initiates a web connection to Cisco.com. The Cisco ASA is configured to perform authentication (cut-through proxy) and prompts the user for authentication credentials.
- step 2. The user replies with his credentials.
- step 3. The Cisco ASA sends the RADIUS authentication request (Access-Accept) to the CiscoSecure ACS server.
- step 4. The CiscoSecure ACS server authenticates the user and sends a RADIUS response (Access-Accept), including an ACL name associated with the user.
- step 5. The Cisco ASA verifies whether it has an ACL named the same as the one downloaded from the CiscoSecure ACS server. There is no need to download a new ACL if an ACL is identified with the same name.
You can configure downloadable ACLs in CiscoSecure ACS in a few different ways:
- Configure a Shared Profile Component (SPC), including both the ACL name and the actual ACL. This enables you to apply the ACL to any number of users within CiscoSecure ACS.
- Configure each ACL entry within a specific user profile.
- Configure the ACLs to be applied to a specific group.
These options are supported with Cisco ASA to better fit your security policies.