Cisco Acs 57 User Guide

							7   
Understanding Logging
About Logging
Remote Syslog Server Target
You can use the web interface to configure logging category messages so that they are sent to remote syslog server 
targets. Log messages are sent to the remote syslog server targets in accordance with the syslog protocol standard (see 
RFC-3164). The syslog protocol is an unsecure UDP.
Log messages are sent to the remote syslog server with this syslog message header format, which precedes the local 
store syslog message format (see Table 37 on page 5):
pri_num YYYY Mmm DD hh:mm:ss xx:xx:xx:xx/host_name cat_name msg_id total_seg seg_num
Table 38 on page 7 describes the content of the remote syslog message header format.
Table 38 Remote Syslog Message Header Format
Field Description
pri_num Priority value of the message; a combination of the facility value and the severity value of the 
message. Priority value = (facility value* 8) + severity value. The facility code valid options are:
LOCAL0 (Code = 16)
LOCAL1 (Code = 17)
LOCAL2 (Code = 18)
LOCAL3 (Code = 19)
LOCAL4 (Code = 20)
LOCAL5 (Code = 21)
LOCAL6 (Code = 22; default)
LOCAL7 (Code = 23)
Severity value—See Table 36 on page 4 for severity values.
time Date of the message generation, according to the local clock of the originating ACS, in the format 
YYYY Mmm DD hh:mm:ss. Possible values are:
YYYY = Numeric representation of the year.
Mmm = Representation of the month—Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, 
Dec.
DD = Numeric representation of the day of the month. For single-digit days (1 to 9), a space 
precedes the number.
hh = The hour of the day—00 to 23.
mm = The minute of the hour—00 to 59.
ss = The second of the minute—00 to 59.
Some device send messages that specify a time zone in the format -/+hhmm, where - and + 
identifies the directional offset from the ACS server’s time zone, hh is the number of offset hours, 
and mm is the number of minutes of the offset hour. For example, +02:00 indicates that the 
message occurred at the time indicated by the time stamp, and on an ACS node that is two hours 
ahead of the ACS server’s time zone.
xx:xx:xx:xx/host_name IP address of the originating ACS, or the hostname. 
						

							8
Understanding Logging
 
About Logging
The syslog message data or payload is the same as the Local Store Message Format, which is described in Table 37 on 
page 5.
The remote syslog server targets are identified by the facility code names LOCAL0 to LOCAL7 (LOCAL6 is the default 
logging location.) Log messages that you assign to the remote syslog server are sent to the default location for Linux 
syslog (/var/log/messages), however; you can configure a different location on the server. 
The remote syslog server cannot function as a critical log target. See Critical Log Target, page 6 for more information on 
critical log targets.
Monitoring and Reports Server Target
You can use the web interface to configure logging category messages so that they are sent to the Monitoring and 
Reports server target. Log messages are sent to the Monitoring and Reports server target in accordance with the syslog 
protocol standard (see RFC-3164). The syslog protocol is an unsecure UDP protocol.
Log messages are sent to the Monitoring and Reports server with the syslog message header format described in 
Table 38 on page 7, which precedes the local store syslog message format (see Table 37 on page 5).
The Monitoring and Reports server cannot function as a critical log target. See Critical Log Target, page 6 for more 
information on critical log targets.
Viewing Log Messages
You can use the web interface and the CLI to view locally stored log messages. You cannot view log messages that are 
sent to remote syslog servers via the web interface or the CLI. 
In the web interface, choose Monitoring and Reports > Launch Monitoring and Report Viewer to open the Monitoring 
and Reports Viewer in a secondary window (see Figure 2 on page 9). See Command Line Interface Reference Guide for 
Cisco Secure Access Control System 5.7 for more information about viewing log messages via the CLI. cat_name Logging category name preceded by the 
CSCOacs string. 
msg_id Unique message ID; 1 to 4294967295. The message ID increases by 1 with each new message. 
Message IDs restart at 1 each time the application is restarted.
total_seg Total number of segments in a log message. Long messages are divided into more than one 
segment.
seg_num Segment sequence number within a message. Use this number to determine what segment of the 
message you are viewing.
Table 38 Remote Syslog Message Header Format (continued)
Field Description 
						

							9   
Understanding Logging
ACS 4.x Versus ACS 5.7 Logging
Figure 2 Monitoring and Reports Viewer
The Monitoring and Report Viewer has two drawer options:
Monitoring and Reports—Use this drawer to view and configure alarms, view log reports, and perform 
troubleshooting tasks.
Monitoring Configuration—Use this drawer to view and configure logging operations and system settings.
In addition to the information that is captured in the log messages described in Logging Categories, page 2, the Viewer 
reports list successful and failed AAA authentication attempts with Step attributes. Step attributes provide information 
about other events that occurred within the same session. This information allows you to see the sequence of steps that 
resulted in an authentication success or failure.
You can use the Viewer to: 
Manage alarms, reports, and troubleshooting information.
Manage system operations, including purging data, collecting logs, scheduling jobs, and monitoring status
Manage system configuration, including editing failure reasons, and configuring e-mail, session directory, and alarm 
settings
See Monitoring and Reporting in ACS, page 1 for more information
Debug Logs
You can use the web interface and the CLI to send logs, including debug logs, to Cisco technical support personnel if 
you need troubleshooting assistance. In the web interface, choose Monitoring and Reports > Launch Monitoring and 
Report Viewer > Monitoring and Reports > Troubleshooting > ACS Support Bundle.
You can also use the CLI to view and export the hardware server in the Application Deployment Engine-OS 1.2 
environment logs. These messages are sent to /var/log/boot.log only and are unrelated to the way in which the CLI views 
or exports ACS debug log messages. See the Command Line Interface Reference Guide for Cisco Secure Access Control 
System 5.7 for information.
ACS 4.x Versus ACS 5.7 Logging
If you are familiar with the logging functionality in ACS 4.x, ensure that you familiarize yourself with the logging 
functionality of ACS 5.7, which is considerably different. Table 39 on page 10 describes the differences between the 
logging functionality of ACS 4.x and ACS 5.7. 
						

							10
Understanding Logging
 
ACS 4.x Versus ACS 5.7 Logging
Table 39 ACS 4.x vs. ACS 5.7 Logging Functionality
This logging function… is handled this way in ACS 4.x… and this way in ACS 5.7
Log TypesAAA-related logs contain information 
about the use of remote access 
services by users. 
Audit logs contain information about 
the ACS system and activities and, 
therefore, record system-related 
events. 
These logs are useful for 
troubleshooting or audits. CSV audit 
logs are always enabled, and you can 
enable or disable audit logs to other 
loggers. You cannot configure the 
audit log content.
Audit logs can display the actual 
changes administrators have made for 
each user. ACS audit logs list all the 
attributes that were changed for a 
given user. See Logging Categories, page 2.
Available Log TargetsCSV Logger 
Syslog Logger
ODBC Logger
Remote Logging See Remote Syslog Server Target, page 7 
and Local Store Target, page 4.
Log File LocationsCSV Logger: 
sysdrive
:\Program Files\CiscoSecur
e ACS v
x.x.Local store target logs: 
/opt/CSCOacs/logs/localStore/.
Remote syslog server target logs: 
/var/log/messages.
Report TypesCSV
Dynamic Administration
EntitlementSee Monitoring and Reporting in ACS, 
page 1.
Error Codes and Message Text For ACS 4.2, CSAuth diagnostic logs 
display a description of client requests and 
responses. Previous versions of ACS used 
a numeric code for client requests and 
responses.All messages, see Viewing Log Messages, 
page 8. 
						

							11   
Understanding Logging
ACS 4.x Versus ACS 5.7 Logging
Configuration Use the System Configuration > Logging 
page to define:
Loggers and individual logs
Critical loggers
Remote logging
CSV log file
Syslog log
ODBC logSee Configuring Local and Remote Log 
Storage, page 23 and the CLI Reference 
Guide for Cisco Secure Access Control 
System 5.7.
Viewing and Downloading Log 
MessagesUse the Reports and Activity pages. See Viewing Log Messages, page 8.
Troubleshooting with Log 
MessagesService log files reside in the \Logs 
subdirectory of the applicable service 
directory.See Debug Logs, page 9.
Table 39 ACS 4.x vs. ACS 5.7 Logging Functionality (continued)
This logging function… is handled this way in ACS 4.x… and this way in ACS 5.7 
						

							12
Understanding Logging
 
ACS 4.x Versus ACS 5.7 Logging 
						

							1
Cisco Systems, Inc.www.cisco.com
 
AAA Protocols
This section contains the following topics:
Typical Use Cases, page 1
Access Protocols—TACACS+ and RADIUS, page 4
Overview of TACACS+, page 5
Overview of RADIUS, page 5
Typical Use Cases
This section contains the following topics:
Device Administration (TACACS+), page 1
Network Access (RADIUS With and Without EAP), page 2
Device Administration (TACACS+)
Figure 3 on page 1 shows the flows associated with device administration. The two primary triggers are:
Session Access Requests (Device Administration [TACACS+]), page 1.
Command Authorization Requests, page 2.
Figure 3 Device Administration Flow 
Session Access Requests (Device Administration [TACACS+])
Note: The numbers refer to Figure 3Device Administration Flow, page 1.
For session request:
1.An administrator logs into a network device.
2.The network device sends a TACACS+ access request to ACS. 
3.ACS uses an identity store to validate the user's credentials.
Host
Network device
12
4
ACS runtime3
Identity 
store
250850 
						

							2
AAA Protocols
 
Typical Use Cases
4.ACS sends a TACACS+ response to the network device that applies the decision. The response includes 
parameters, such as the privilege level that determines the level of administrator access for the duration of the 
session.
Command Authorization Requests
Note: The numbers refer to Figure 3Device Administration Flow, page 1.
For command authorization:
1.An administrator issues a command at a network device.
2.The network device sends a TACACS+ access request to ACS. 
3.ACS optionally uses an identity store to retrieve user attributes for inclusion in policy processing.
4.The TACACS+ response indicates whether the administrator is authorized to issue the command.
Network Access (RADIUS With and Without EAP)
For network access, a host connects to the network device and requests to use network resources. The network device 
identifies the newly connected host, and, using the RADIUS protocol as a transport mechanism, requests ACS to 
authenticate and authorize the user.
ACS 5.7 supports the following categories of network access flows, depending on the protocol that is transported over 
the RADIUS protocol:
RADIUS-based protocols that do not include EAP:
—PA P
—CHAP
—MSCHAPv1
—MSCHAPv2
For more information on RADIUS-based protocols that do not include EAP, see RADIUS-Based Flow Without EAP 
Authentication, page 3.
EAP family of protocols transported over RADIUS, which can be further classified as:
—Simple EAP protocols that do not use certificates:
EAP-MD5
LEAP
—EAP protocols that involve a TLS handshake and in which the client uses the ACS server certificate to perform 
server authentication:
PEAP, using one of the following inner methods: PEAP/EAP-MSCHAPv2 and PEAP/EAP-GTC
EAP-FAST, using one of the following inner methods: EAP-FAST/EAP-MSCHAPv2 and EAP-FAST/EAP-GTC
—EAP protocols that are fully certificate-based, in which the TLS handshake uses certificates for both server and 
client authentication:
EAP-TLS
PEAP with inner method EAP-TLS 
						

							3   
AAA Protocols
Typical Use Cases
For more information on RADIUS-based flows with EAP authentication, see RADIUS-Based Flows with EAP 
Authentication, page 3.
RADIUS-Based Flow Without EAP Authentication
This section describes RADIUS-based workflow without EAP authentication.
For RADIUS with PAP authentication:
1.A host connects to a network device.
2.The network device sends a RADIUS Access-Request to ACS, containing RADIUS attributes appropriate to the 
specific protocol that is being used (PAP, CHAP, MSCHAPv1, or MSCHAPv2).
3.ACS uses an identity store to validate the user's credentials. 
4.The RADIUS response (Access-Accept or Access-Reject) is sent to the network device that will apply the decision. 
Figure 4 on page 3 shows a RADIUS-based authentication without EAP.
Figure 4 RADIUS-Based Flow Without EAP Authentication
RADIUS-Based Flows with EAP Authentication
EAP provides an extensible framework that supports a variety of authentication types. Among them, the specific EAP 
methods supported by ACS are:
Simple EAP methods that do not use certificates:
—EAP-MD5
—LEAP
EAP methods in which the client uses the ACS server certificate to perform server authentication:
—PEAP/EAP-MSCHAPv2
—PEAP/EAP-GTC
—EAP-FAST/EAP-MSCHAPv2
—EAP-FAST/EAP-GTC
EAP methods that use certificates for both server and client authentication
—EAP-TLS
—PEAP/EAP-TLS
Whenever EAP is involved in the authentication process, it is preceded by an EAP negotiation phase to determine which 
specific EAP method (and inner method, if applicable) should be used.
2
4
6
3
Host
Network device
ACS Runtime5
Identity 
store
250851
1 
						

							4
AAA Protocols
 
Access Protocols—TACACS+ and RADIUS
For all EAP authentications:
1.A host connects to a network device.
2.The network device sends an EAP Request to the host.
3.The host replies with an EAP Response to the network device.
4.The network device encapsulates the EAP Response that it received from the host into a RADIUS Access-Request 
(using the EAP-Message RADIUS attribute) and sends the RADIUS Access-Request to ACS.
5.ACS extracts the EAP Response from the RADIUS packet and creates a new EAP Request, encapsulates it into a 
RADIUS Access-Challenge (again, using the EAP-Message RADIUS attribute), and sends it to the network device.
6.The network device extracts the EAP Request and sends it to the host.
In this way, the host and ACS indirectly exchange EAP messages (transported over RADIUS and passed through the 
network device). The initial set of EAP messages that are exchanged in this manner negotiate the specific EAP method 
that will subsequently be used to perform the authentication.
The EAP messages that are subsequently exchanged are then used to carry the data needed to perform the actual 
authentication. If required by the specific EAP authentication method that is negotiated, ACS uses an identity store to 
validate the user's credentials.
After ACS determines whether the authentication should pass or fail, it sends either an EAP-Success or EAP-Failure 
message, encapsulated into a RADIUS Access-Accept or Access-Reject message to the network device (and ultimately 
also to the host).
Figure 5 on page 4 shows a RADIUS-based authentication with EAP.
Figure 5 RADIUS-Based Authentication with EAP
For a list of known supplicant issues that might impact your ACS 5.7 experience, see Release Notes for Cisco Secure 
Access Control System 5.7. 
Access Protocols—TACACS+ and RADIUS
This section contains the following topics:
Overview of TACACS+, page 5
Overview of RADIUS, page 5
ACS 5.7 can use the TACACS+ and RADIUS access protocols. Table 40 on page 5 compares the two protocols.
2
4
6
3
Host
Network device
ACS Runtime5
Identity 
store
250851
1