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.

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.

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

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

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