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.

Note

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 16.

The aaa authorization 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 include | exclude svc if_name l_ip l_mask [f_ip f_mask]server_tag

Table 7-7 lists its options.

Table 7-7. aaa authorization Command Options for Firewall Cut-Through Proxy Sessions

Option

Description

include

Use this option to include authorization services for a specific host or network.

exclude

Use this option to exclude authorization services for a specific host or network.

svc

Specifies the protocol and/or service used:

telnet, ftp, http, https, tcp/port, and tcp/0.

if_name

Name of the interface on which authorized connections are originated.

l_ip

The address of the local host or network that requires authorization.

l_mask

The network mask of the local host or network that requires authorization.

f_ip

The address of the foreign host or network whose connections require authorization.

f_mask

The network mask of the foreign host or network whose connections require authorization.

server_tag

The name of the AAA server tag. For cut-through and command authorization, the server tag LOCAL can also be used. Only TACACS+ is supported for cut-through authorization.

You can also use the aaa authorization match command to define a firewall cut-through proxy session:

aaa authorization match access_list_name if_name server_tag

The access_list_name option specifies the ACL name used to categorize which traffic requires authorization. Example 7-16 demonstrates how to use this command.

Example 7-16. Enabling Authorization Using an ACL to Define Interesting Traffic

access-list 100 extended permit ip 10.10.10.0 255.255.255.0 192.168.1.0 255.255.255.0 aaa-server mygroup protocol tacacs+ aaa-server mygroup host 10.10.10.100 key cisco123 aaa authorization match 100 inside mygroup

In Example 7-16, access list 100 defines that all IP traffic sourced from the 10.10.10.0/24 network destined to 192.168.1.0/24 requires authorization. This ACL is associated to the aaa authorization match command.

Command Authorization

To configure command authorization on the Cisco ASA, the following command is used:

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.

Tip

Establishing two separate sessions to the Cisco ASA is always recommended when configuring AAA authorization. The purpose of this procedure is to avoid getting locked out of the CLI. Open one session using a Telnet or SSH connection and connect to the serial console of the Cisco ASA. One of the sessions can be disconnected once the configuration is verified and tested.

When using authorization, the following attributes are passed to the TACACS+ server in the attribute payload of the authorization request message:

The following attributes may be received from a TACACS+ server in an authorization response message:

Configuring Downloadable ACLs

Cisco ASA provides support for a per-user ACL authorization by downloading 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 will work in combination with the ACLs configured in the ASA. The user traffic needs to be permitted by both ACLs in order 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

All downloadable ACLs are applied to the interface from which the user is authenticated.

Figure 7-7 illustrates an example of how downloadable ACLs work.

Figure 7-7. Downloadable ACL Example

The following are the steps listed in Figure 7-7:

  1. A user initiates a web connection to Cisco.com.

  2. The Cisco ASA is configured to perform authentication (cut-through proxy) and prompts the user for authentication credentials.

  3. The user replies with his credentials.

  4. The Cisco ASA sends the RADIUS authentication request (Access-Accept) to the CiscoSecure ACS server.

  5. The CiscoSecure ACS server authenticates the user and sends a RADIUS response (Access-Accept) including an ACL name associated with the user.

  6. 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 there is an ACL identified with the same name.

You can configure downloadable ACLs in CiscoSecure ACS in a few different ways:

These options are supported with Cisco ASA to better fit your security policies.

Related

Категории