Step 1. | Select Access Policies > Access Service you want to change > Authorization. For this example, select Authorization under Remote Access VPN. The Authorization Policy page appears. |
Step 2. | Rules of an authorization policy use session conditions to determine which authorization and permissions to use for a request. The session conditions available in the Rules Properties page need to be enabled from the Authorization Policy page. Click Customize to open the Customize Conditions dialog box. Select the conditions that you want to use. For this example, deselect default conditions and select Identity Group. |
Step 3. | If the authorization policy for a TACACS+-based access service is being configured, then along with available session conditions, you will need to select available results in the Customize dialog box. Results can be shell profiles or command sets. For this example, you will not have an option to select results because the access service is RADIUS-based. Authorization Profile is the only result available with such access services. |
Step 4. | Click Create. The Authorization Rule properties page appears as shown in Figure 4-24. |
Step 5. | Enter a name. For this example, use Admins. |
Step 6. | Select a session condition. For this example, select Identity Group. |
Step 7. | Select an operator from the drop-down box next to the selected condition. The available operators change depending on the condition selected. These are logical operators that allow matching or not matching a user-provided argument with the selected condition. For our example, select in from the drop-down box. |
Step 8. | For some conditions, such as Identity Group, you will see a Select button next to the condition. You can click this button to select the required element. For some conditions your will get a drop-down box or a text box. For this example, click Select and select the Admin group you created earlier. |
Step 9. | Authorization profiles require you to select a result. Results can be authorization profiles, shell profiles, or command sets depending on the access service. Click Select next to the result that you want to configure and select a policy element. For this example, select the Permit Access authorization profile, which is available by default. |
Step 10. | Click OK. The rule will be saved and the Authorization Policy page will appear with the new rule listed in the table. |
Creating the Rules of an Authorization Policy
You have created your first authorization rule, which permits access if the user belongs to the Admin Identity group.
Now that the access service configuration is complete, you will need to create a service selection rule so that this service is used.
Creating Service Selection Rules
As you know, service selection rules decide which access service to apply to a request. By default ACS is configured for rule-based service selection. Two rules are present by default. The first rule, named Rule-1, sends all RADIUS requests to the Default Network Access service and the second rule, named Rule-2, sends all TACACS+ requests to the Default Device Admin service. To configure ACS to use the Remote Access VPN service that you created, you need to add a new rule for service selection. You have the following choices in this situation:
Edit Rule-1 to send all requests to the Remote Access VPN service
Delete Rule-1 and create a new rule
Create a new rule above Rule-1 that is specific to the Remote Access VPN service
For this example, create a new rule above Rule-1. To do so, follow these steps:
Step 1. | Select Access Policies > Access Services > Service Selection Rules. The Service Selection Policy page appears. |
Step 2. | The session conditions available in a service selection rule properties page can be customized from this page. Click Customize and select the required conditions. For this example, select NDG:Location and Protocol. |
Step 3. | Select Rule-1 and click the down arrow on the Create button. |
Step 4. | Select Create Above. The Service Selection Rules properties page appears as shown in Figure 4-25. |
Step 5. | Enter a name. For this example, use San Jose VPN. |
Step 6. | Select the conditions that define the rule. For this example, select Protocol and NDG:Location. |
Step 7. | Select an operator from the drop-down box next to the selected condition. The available operators change depending on the condition selected. These are logical operators that allow matching or not matching a user-provided argument with the selected condition. For this example, select match for Protocol and in for NDG:Location. |
Step 8. | For some conditions, such as NDG:Location, you will see a Select button next to the condition. You can click this button to select the required element. For some conditions, you will get a drop-down box or a text box. For this example, click Select and select San Jose for NDG:Location and RADIUS for Protocol. If you have not created the San Jose group, select the All Locations option for NDG:Location. |
Step 9. | The result of a service selection rule is an access service or DenyAccess. You can use the drop-down box to select the result for the rule. For this example, select Remote Access VPN from the drop-down box. |
Step 10. | Click Ok. The rule will be saved and the Service Selection Policy page will appear with the new rule listed above Rule-1 in the table. |
Creating a Service Selection Rule
The rule you created will send RADIUS requests originating from devices in the San Jose NDG or All Locations NDG to the Remote Access VPN access service which you created earlier. The access service and policies that you created in the previous sections will authenticate RADIUS requests originating from a device in the Core Routers NDG using the Internal User identity store. If authentication is successful and the user belongs to the Admin identity group, the access will be permitted. Further chapters will help you create more complex access services and policies. The examples in this chapter are used to explain the basic process of creating policies and rules.
Monitoring and Reports
The Monitoring and Reports drawer replaces the Reports and Activity section of previous versions of ACS. You can now view reports based on different criteria such as Access Service, End Point, and Failure Reason, among others. ACS 5.x also introduces a configurable dashboard for reports and alarms.
Note - ACS 5.x has added monitoring, reporting, and troubleshooting capabilities that are similar to those available is ACSView 4.0. ACSView is an independent reporting and monitoring platform available for ACS 4.x.
Covering the entire Monitoring and Reports section in depth is beyond the scope of this book. This section of the text will focus on the reports that are most important and touch on the rest briefly.
The Monitoring and Reports drawer contains the Launch Monitoring and Report Viewer option. Click this option to open the Monitoring and Reports Viewer in another browser window or tab. The layout of the new window is similar to the main window but contains only the following two drawers:
Monitoring and Reports
Monitoring Configuration
The Monitoring and Reports drawer contains the following options:
DashBoard: ACS 5.1 provides a new customizable dashboard that contains tabs and portlets where your favorite queries, recent alarms and reports, and health status of ACS reside. Each of these tabs can have multiple portlets, with each portlet containing an application of your choice. You can select an application from the available list. Some of the important applications available in the dashboard by default are as follows:
- Recent Five Alarms: This application is available in the General tab and shows the latest five alarms.
- Favorite Reports: This application contains links to favorite reports. The favorite list is configuration from the Reports option discussed later.
- Live Authentications: This application is available in the Troubleshooting tab and shows authentication requests received in real time. This is a very useful application for troubleshooting. By default, it refreshes every 10 seconds and is configured to monitor RADIUS requests.
- NAD Show Command: A neat little application that can connect to a network device using SSH or Telnet and run a show command. You have to provide the login details and the show command to run. ACS will display the output in a new window. This is also a very useful application. It saves you from jumping between ACS GUI and Telnet or SSH clients.
- ACS Health Status: Shows the health of the ACS server.
Alarms: ACS 5.x introduces alarms. The monitoring component retrieves data from ACS and generates alarms to notify you of critical system conditions. These alarms can be viewed in the Inbox option in this drawer or can be received through Syslog and email. There are two types of alarms in ACS: Threshold and System. Threshold alarms are defined on logs collected from ACS. You can configure a threshold alarm to notify you of different events such as authentication activity, system health, and process status, among others. System alarms notify you of critical conditions encountered during the execution of the ACS Monitoring and Reporting viewer. System alarms also provide the informational status of system activities, such as data purge events or the failure of the log collector to populate the View database. You cannot configure system alarms. This drawer contains the following options:
- Inbox: Generated alarms can be viewed in the Inbox. After you view an alarm, you can edit the status of the alarm, assign the alarm to an administrator, and add notes to track the event.
- Thresholds: You can configure thresholds from this page. A maximum of 100 thresholds can be configured in an ACS server. Four thresholds exist by default, out of which only the System Errors threshold is enabled.
- Schedules: Each threshold has a schedule associated with it. The schedule defines when a threshold is run. You need to configure schedules on this page before you can use them in thresholds. By default, ACS has a nonstop schedule that monitors events 24 hours a day, seven days a week.
Reports: The Reports section contains different predefined reports that you can use to monitor and troubleshoot ACS. These reports include authentication and authorization reports (similar to passed and failed reports from ACS 4.x), access service reports, ACS configuration and operation audits, and network device summary, among others. You can add any of the reports to your Favorites and those will be displayed in the General tab of the dashboard. The following report categories are available in the catalog:
- AAA Protocol: Contains RADIUS and TACACS+ authentication, authorization (TACACS+ only) and accounting reports, AAA diagnostics, and authentication trend. Passed and failed logs from previous ACS version have been divided into protocol-specific authentication and authorization reports. Figure 4-26 shows the TACACS+ authentication report.
Figure 4-26
TACACS+ Authentication Report
- Access Service: Contains a graphical summary report and a top count report for authentication in respect to access services.
- ACS Instance: Contains different system-related reports such as configuration and operations audit reports, health summary, administrator logins and entitlement reports, and ACS system diagnostics.
- Endpoint: Contains MAC address-based authentication summary reports, MAC address-based top authentications reports, and machine-based top authentication reports.
- Failure Reason: Contains summary and top authentication failure reports. This is one of the most important reporting sections. A close look at this section can tell you about any access attacks being carried out against your network.
- Network Device: Contains summary and top authentication reports in respect to network devices. These reports are useful in tracking which devices are generating the maximum number of requests.
- Session Directory: Contains active session, terminated sessions, and session history reports for RADIUS and TACACS+. Accounting packets received from devices are used to maintain session information.
User: Contains summary and top authentication reports in respect to users.
Troubleshooting: ACS 5.x contains some nice troubleshooting options. The following options are available in the Troubleshooting section:
Connectivity Tests: You can run a ping, traceroute, and nslookup for a hostname or IP address to see whether the device is reachable from ACS. This is important to see whether the requests from a device and replies from ACS to the device are not getting dropped in the network.
ACS Support Bundle: The support bundle is a zip archive of diagnostic information, including system log files. You can also choose to include ACS configuration, ACS debug log files, ACS localstore log files, and core files. This support bundle will be needed by the Cisco Technical Assistance Center (TAC) for troubleshooting.
Expert Troubleshooter: This section contains some nice tools to check the configuration of a device and ACS. Using RADIUS Authentication troubleshooting tool, you can select a failed or passed log from RADIUS authentication report and have it check the ACS and device configuration to see why the authentication failed or passed. Figure 4-27 shows the report generated by this tool when changing the RADIUS shared key on the device. This section also contains the NAD show command application from the dashboard and the Evaluate Configuration Validator, which checks the configuration of a device to see whether it is configured properly for a task such as 802.1x authentication.
- Figure 4-27
RADIUS Authentication Troubleshooting Tool at Work
The Monitoring Configuration drawer contains various configuration options for the Monitoring and Report Viewer. Configuration of ACS View (the Monitoring and Reporting part of ACS 5.x) is out of the scope of this book.
Note - The System Administration drawer contains various advanced configuration options for ACS. These options are covered in Chapter 15.
ACS 5.1 Command-Line Interface (CLI)
ACS 5.x, unlike previous versions, provides a CLI for configuration and monitoring along with a GUI. You can access the ACS CLI through a secure shell (SSH) client or the console port.
Two different types of accounts are available for accessing the CLI:
Admin: Admin accounts have full configuration and monitoring access.
Operator: Operator accounts have monitoring access only.
This section assumes use of an Admin account to access the CLI.
The ACS CLI is similar to IOS CLI in look, feel, modes, and command structure. You can use the question mark (?) to see the help and the Tab key to complete a command. Logging in to the ACS server places you in the Operator (user) mode or the Admin (EXEC) mode. Typically, logging in requires a username and password.
You can always tell when you are in the Operator (user) mode or Admin (EXEC) mode by looking at the prompt. A right angle bracket (>) appears at the end of the Operator (user) mode prompt; a pound sign (#) appears at the end of the Admin mode prompt, regardless of the submode.
Three command modes are available on the CLI: