| 13.5 |  | Command Authorization |
| 13.5.4 |  | (Method 3) ACS command authorization |

| ACS command authorization ACS command authorization differs from LOCAL command authorization in that usernames and accounts are defined in a remote Terminal Access Controller Access Control System+ (TACACS+) server instead of in the PIX Security Appliance LOCAL database. ACS command authorization is more scalable than LOCAL command authorization, because it allows central management of the login process. However, as is outlined below, it is critical that both the network and TACACS+ servers be highly reliable before implementing this solution.

Implementation of ACS command authorization is very similar to implementation of LOCAL command authorization. The key difference is that the aaa authorization command is used to specify a TACACS+ server instead of the local PIX database.

The Command Reference illustrates the aaa authorization command as it is utilized by ACS command authorization. The privilege and aaa authentication commands were covered in the previous sections.

Before configuring ACS command authorization
Before enabling authorization with ACS, it is important that administrators make sure that certain requirements have been fulfilled. This is needed to ensure that they do not get locked out of the PIX Security Appliance. Administrators should ensure the following:

- The entries for enable_1, enable_15, and any other levels have been created and the appropriate commands have been assigned.
- If authentication is being enabled with usernames, a user profile on the TACACS+ server must be present, with all the commands that the user is permitted to execute.
- The TACACS+ server is fully tested.
- The administrator is logged in as a user with the necessary privileges.
- The TACACS+ system is completely stable and reliable. The necessary level of reliability typically requires the existence of a fully redundant TACACS+ server system and fully redundant connectivity to the PIX Security Appliance.

When configuring the command authorization feature, do not save the configuration until confirming that the features work as advertised.

If the administrator gets becomes locked out of the PIX Security Appliance, access can usually be recovered by simply reloading the PIX Security Appliance. If it is not possible to recover access to the PIX Security Appliance by restarting the PIX Security Appliance, refer to the Cisco Web site listed below. This Web site provides a downloadable file and instructions on how to remove the lines in the PIX Security Appliance configuration that enable authentication and cause the lockout problem.

If the configuration has already been saved, but the LOCAL database being used for authentication does not have any usernames configured on it, a lockout problem has been created. Additionally, a lockout problem can occur if command authorization has been configured using TACACS+, but the TACACS+ server is unavailable, down, or misconfigured.

A different lockout problem can be encountered if the aaa authorization command and tacacs_server_tag argument are used, and the administrator is not logged in as the correct user. For every command entered, the PIX Security Appliance displays the following message:

Command Authorization failed

This occurs because the TACACS+ server does not have a user profile for the user account that was used to log in. To prevent this problem, make sure that the TACACS+ server has all the users configured with the commands that they can execute. Also, the administrators need to make certain that they are logged in as a user with the required profile on the TACACS+ server.

Verifying command authorization
Regardless of which method of command authorization a network administrator chooses, it is important that they are able to view and troubleshoot the feature once it has been configured. The Command Reference discusses two useful show commands that can be used for this purpose.