ACS Reports

ACS can provide numerous reports such as accounting reports, administrative reports, and system reports, among others. Some of these reports that ACS maintains might contain information from multiple sources and for multiple reasons. For example, ACS might log a failed password authentication attempt to the Failed Attempts log, and in the same log, you might find a failed attempt caused by an unknown AAA client attempting to communicate with ACS. This is where the third-party reporting programs, such as aaa-reports by Extraxi, SQL, or Microsoft Access can provide enhanced functionality by allowing you to pick the logs apart and see only what you want to see.

Accounting Reports

ACS also maintains TACACS+, RADIUS, and Voice over IP (VoIP) accounting reports, which contain records of successful authentications during selected time periods. In addition to logging successful authentications, these logs contain information such as time/date, username, type of connection, amount of time logged in, and bytes transferred.

Accounting logs contain information about the use of remote access services by users. By default, these report logs are available in CSV format. With the exception of the Passed Authentications log, you can also configure ACS to export the data for these logs to an ODBC-compliant relational database.

TACACS+ Accounting

The TACACS+ accounting report logs contain user sessions' stop and start times, AAA client messages with username, caller line identification information, and session duration. The TACACS+ accounting report is seen in Figure 12-10.

Figure 12-10. TACACS+ Accounting Report

RADIUS Accounting

RADIUS accounting files contain the following information: user sessions' stop and start times, AAA client messages with username, caller line identification information, and session duration. The RADIUS accounting report is seen in Figure 12-11.

Figure 12-11. RADIUS Accounting Report

You can also configure ACS to include accounting for VoIP in this RADIUS accounting report log or in a separate VoIP accounting log. This is seen in the next section, "VoIP Accounting."

VoIP Accounting

Another type of accounting report that ACS provides is for VoIP. This accounting information can be found in the RADIUS accounting report log or optionally in a separate VoIP accounting report log. You might want to send VoIP accounting to both report logs. These reports can be configured in the System Configuration page under the Logging link.

VoIP accounting reports contain the following information:

VoIP session stop and start times
AAA client messages with username
Calling line identification (CLID) information
VoIP session duration

As previously mentioned, you can configure ACS to include accounting for VoIP in this separate VoIP accounting log, in the RADIUS accounting log, or in both places.

Failed Attempts Report

The Failed Attempts report provides you with information related to authentication attempts that were not successful. From this report, you can gather information such as the username attempting to authenticate as well as the IP address that they made the attempt from. You also receive information to guide you in the direction you should look if authentication is not successful. An example of this would be a failed authentication attempt to an external database. In this situation, you receive a message similar to the following: External DB user invalid or bad password.

In cases such as this, you might need to reset the user password in the external database or verify that the password entered is correct. Another example is seen in Figure 12-12. As you can see, authentication has failed for user admin. The reason authentication has failed is noted in the Authen-Failure-Code field. In this case, the CS in the report stands for CiscoSecure, so the password the user is entering is being matched to the ACS internal database and is invalid.

Figure 12-12. Failed Authentications Report with Invalid CS Password

In the Failed Authentications report, you not only see failed authentications by users, but also remember that ACS authenticated the AAA clients that it communicates with using a shared secret key. In Figure 12-13, you see an example that is very common. In the example, the Authen-Failure-Code field tells us that there is a key mismatch. Note here that no user is listed in the User-Name field. This is because the key mismatch is between the AAA client192.168.198.128 and ACS. This caused the authentication between ACS and the AAA client to fail.

Figure 12-13. Failed Authentications Report with Key Mismatch

Passed Authentications Report

Passed Authentications gives you information about successful authentications. This report includes the following information:

Date
Time
Message-Type
User-Name
Group-Name
Caller-ID
NAS-Port
NAS-IP-Address

An example of the Passed Authentications report is seen in Figure 12-14.

Figure 12-14. Passed Authentications Report

Administrative Reports

Three different administrative reports exist in ACS: TACACS+ Administration, Logged-in Users, and Disabled Accounts. Of the three reports, TACACS+ Administration is not dynamic. It records information as it happens and can be downloaded in CSV format. The other two reports are dynamic.

TACACS+ Administration Report

The administrative report contains information about all the TACACS+ commands requested during the period of time covered in the report. This report is used most often when you are using ACS to control access to network devices or when using command authorization sets.

To use the TACACS+ Administration log, you must configure TACACS+ AAA clients to perform command accounting with ACS. The command authorization configuration is covered in Chapter 10, "Configuring Shared Profile Components." An example of the TACACS+ Administration Report is seen in Figure 12-15.

Figure 12-15. TACACS+ Administration Report

Logged-In Users and Disabled Accounts Reports

The last two administrative reports are dynamic in nature, meaning that they populate based on the current status of ACS. The dynamic administrative reports have the following traits:

Logged-in Users The Logged-in Users report lists all users receiving services from a single AAA client or all AAA clients with access to ACS. For this log to work, you must configure AAA clients to perform authentication and accounting using the same protocoleither TACACS+ or RADIUS. This log does not work if users access the AAA device using Telnet. In Figure 12-16, you can see that the AAA client pixfirewall is logged in to ACS. This means that the AAA client is doing authentication and accounting using the same protocol, which is TACACS+.
Figure 12-16. Logged-in Users Dynamic Report
Disabled Accounts The Disabled Accounts report lists all user accounts that are disabled and the reason they were disabled. From here you can re-enable the account by selecting the username link that accesses the user profile. The Disabled Accounts report is seen in Figure 12-17.
Figure 12-17. Disabled Accounts Report

System Reports

System reports are report logs that record events directly related to ACS and actions it has taken. Examples of these reports are as follows:

ACS Backup and Restore
RDBMS Synchronization
Database Replication
Administration Audit
User Password Changes
ACS Service Monitoring

These reports are discussed in further detail.

ACS Backup and Restore

The ACS Backup and Restore lists ACS backup and restore activity that ACS has taken. This report is not configurable in the interface. The information that gets populated in this log is placed there automatically when a backup occurs, whether it is a scheduled or manual backup. The report is also populated when a restore occurs. In Figure 12-18, you can see that a backup and a restore has taken place. You can also see the location of the dump file used for backup.

Figure 12-18. Backup and Restore Report

RDBMS Synchronization

The RDBMS Synchronization report lists RDBMS Synchronization activity. This report cannot be configured.

Database Replication

The Database Replication report lists database replication activity. This report also cannot be configured. In Figure 12-19, you can see an example of a replication that was unsuccessful. It is a good idea to check this report from time to time so that you can verify that replication is being performed successfully.

Figure 12-19. Database Replication Report

Administration Audit

The Administration Audit report lists actions taken by each system administrator, such as adding users, editing groups, configuring an AAA client, or viewing reports. You can see an example of the Administrative Audit report in Figure 12-20.

Figure 12-20. Administrative Audit Report

The Administrative Audit report can be modified. You can configure the administration audit report by following these steps:

Step 1.	Select Administration Control.
Step 2.	Select Audit Policy.
Step 3.	To generate a new Administrative Audit CSV file at a regular interval, select one of the following options: - Every day ACS generates a new Administrative Audit CSV file at the start of each day. - Every week ACS generates a new Administrative Audit CSV file at the start of each week. - Every month ACS generates a new Administrative Audit CSV file at the start of each month.
Step 4.	To generate a new Administrative Audit CSV file when the current file reaches a specific size, select the When size is greater than X KB option.
Step 5.	Type the file size threshold in kilobytes in the X box.

To manage which Administrative Audit CSV files ACS keeps, do the following:

Step 1.	Select the Manage Directory check box.
Step 2.	To limit the number of Administrative Audit CSV files ACS retains, select the Keep only the last X files option and type in the X box the number of files you want ACS to retain.
Step 3.	To limit how old Administrative Audit CSV files retained by ACS can be, select the Delete files older than X days option and type the number of days for which ACS should retain a Administrative Audit CSV file before deleting it.
Step 4.	Select Submit. This completes the process of configuring and managing the Administrative Audit reports.

User Password Changes

The User Password Changes report lists user password changes initiated by users, regardless of which password change mechanism was used to change the password. This log contains records of password changes accomplished by the CiscoSecure authentication agent, by the user changeable password HTML interface, or by Telnet session on a network device using TACACS+. It does not list password changes made by an administrator in the ACS HTML interface.

You can configure this log. If you want ACS to generate a new User Password Changes log file at a regular interval, perform these steps:

Step 1.	Select System Configuration.
Step 2.	Select Local Password Management.
Step 3.	Scroll to the bottom of the page to the Password Change Log File Management section. In this configuration page, you configure options for your log files. The following options are available: - Every day ACS generates a new User Password Changes log file at the start of each day. This creates numerous .csv files. - Every week ACS generates a new User Password Changes log file at the start of each week. These logs are larger than the everyday logs and are easily sorted in third-party software such as Microsoft Access or SQL. - Every month ACS generates a new User Password Changes log file at the start of each month. This file can be very large depending on your password change policy.
Step 4.	If you want ACS to generate a new User Password Changes log file when the current file reaches a specific size, select the When size is greater than X KB option and type the file size threshold, in kilobytes, in the X box.

If you want to manage which User Password Changes log files ACS keeps, follow these steps:

Step 1.	Select the Manage Directory check box.
Step 2.	If you want to limit the number of User Password Changes log files ACS retains, select the Keep only the last X files option and type the number of files you want ACS to retain in the X box.
Step 3.	If you want to limit how old User Password Changes log files retained by ACS can be, select the Delete files older than X days option and type the number of days for which ACS should retain a User Password Changes log file before deleting it.
Step 4.	Select Submit.

This completes the management of ACS User Password Changes log files. These log files can now be viewed in the Reports and Activity section of the ACS HTML interface.

ACS Service Monitoring

The ACS Service Monitoring report is designed to report when the ACS services start and stop. This report is actually built by the CSMon process. When CSMon watches the ACS process and sees the services change, you get a message in this log. You can see an example of this report in Figure 12-21.

Figure 12-21. ACS Service Monitoring

You can also configure this report to log to the Windows Event Log, which is discussed in the next section. To configure ACS service monitoring logs, perform the following tasks:

Step 1.	Select System Configuration.
Step 2.	Select ACS Service Management.

To instruct ACS to test the login process, follow these steps:

Step 1.	Select the Test login process every X minutes check box.
Step 2.	Enter the number of minutes (up to 3 characters) that should pass between each login process test. You can choose to allow for 2 minutes between each login. In this case, you populate the field with the number 2.
Step 3.	From the If no successful authentications are recorded list, select the action that you want ACS to take when the login test fails five times.
Step 4.	To have ACS generate a Windows event when a user attempts to log in to your network using a disabled account, select the Generate event when an attempt is made to log in to a disabled account check box. Event logging can also be configured here to either log events to the Windows event log or to generate an e-mail when an event occurs. To configure event logging, continue with these steps:
Step 5.	Under the Event Logging header, you can send all events to the Windows event log. To do this, select Log all events to the Windows Event log check box.
Step 6.	To send an e-mail notification when an event occurs, select the Email notification of event check box and enter an e-mail address and SMTP server.
Step 7.	Click Submit.

Now your ACS sends you an e-mail as well as logs events to the Windows Event log. To view the Windows Event log, you use the event viewer. Follow these steps to access the viewer in Windows 2000:

Step 1.	Right-click the My Computer Icon on your desktop.
Step 2.	Click Manage.
Step 3.	Double-click in Event Viewer.
Step 4.	Double-click the Application log.

You can now view the service log messages in the Windows Event Viewer. Figure 12-22 shows what this would look like.