Cisco Acs 57 User Guide

							41   
Managing System Administration Configurations
Adding Deployment License Files
Adding Deployment License Files
To add a new base deployment license file:
1.Select System Administration > Configuration > Licensing > Feature Options.
The Feature Options page appears with a description of the ACS deployment configuration and a list of the available 
deployment licenses and their configurations. See Add-on Licenses in Types of Licenses, page 37 for a list of 
deployment licenses. See Viewing License Feature Options, page 40 for field descriptions. 
2.Click Add.
The Feature Options Create page appears. 
3.Complete the fields as described in Table 35 on page 41 to add a license: Expiration Expiration date for the following features:
Large Deployment
SGA
Add/Upgrade Click Add/Upgrade to access the Viewing License Feature Options, page 40 and add a license 
file.
Delete Select the radio button the license feature you wish to delete and click Delete.
Table 34 Feature Options Page   (continued)
Option Description
Table 35 Feature Options Create Page 
Option Description
ACS Deployment Configuration
Primary ACS Instance Name of the primary instance created when you login into the ACS 5.7 web interface.
Number of Instances Current number of ACS instances (primary or secondary) in the ACS database.
Current Number of Configured 
IP Addresses in Network 
DevicesTotal number of IP addresses in all the subnetworks that you have configured as part of 
network device configuration.
The number of devices is determined by the number of unique IP addresses that you 
configure. This includes the subnet masks that you configure. For example, a subnet mask 
of 255.255.255.0 implies 256 unique IP addresses and hence the number of devices is 256.
Maximum Number of IP 
Addresses in Network DevicesMaximum number of IP addresses that your license supports:
Base License—Supports 500 IP addresses.
The number of devices is determined by the number of unique IP addresses that you 
configure. This includes the subnet masks that you configure. For example, a subnet 
mask of 255.255.255.0 implies 256 unique IP addresses and hence the number of 
devices is 256.
Large Deployment—Supports an unlimited number of IP addresses. 
						

							42
Managing System Administration Configurations
 
Deleting Deployment License Files
4.Click Submit to download the license file.
The Feature Options page appears with the additional license.
Related Topics
Licensing Overview, page 36
Types of Licenses, page 37
Installing a License File, page 38
Viewing and Upgrading the Base Server License, page 38
Deleting Deployment License Files, page 42
Deleting Deployment License Files
To delete deployment license files:
1.Select System Administration > Configuration > Licensing > Feature Options.
The Feature Options page appears with a description of the ACS deployment configuration and a list of the available 
deployment licenses and their configurations. See Add-on Licenses in Types of Licenses, page 37 for a list of 
deployment licenses. See the Table 34 on page 40 for field descriptions. 
2.Select the radio button the deployment you wish to delete.
3.Click Delete to delete the license file.
Related Topics
Licensing Overview, page 36
Types of Licenses, page 37
Installing a License File, page 38
Viewing and Upgrading the Base Server License, page 38
Adding Deployment License Files, page 41
Available Downloads
This section contains information about the utilities and files that are available for download from the ACS web interface:
Downloading Migration Utility Files, page 43 Use this link to obtain a valid 
License FileDirects you to Cisco.com to purchase a valid license file from a Cisco representative.
License Location
License File Click Browse to browse to the location of the purchased license file you wish to install and 
select it.
Table 35 Feature Options Create Page   (continued)
Option Description 
						

							43   
Managing System Administration Configurations
Available Downloads
Downloading UCP Web Service Files, page 43
Downloading Sample Python Scripts, page 43
Downloading Rest Services, page 44
Downloading Migration Utility Files
To download migration application files and the migration guide for ACS 5.7:
1.Choose System Administration > Downloads > Migration Utility.
The Migration from 4.x page appears.
2.Click Migration application files, to download the application file you want to use to run the migration utility.
3.Click Migration Guide, to download Migration Guide for Cisco Secure Access Control System 5.7.
Downloading UCP Web Service Files
You can download the WSDL file from this page to integrate ACS with your in-house portals and allow ACS users 
configured in the ACS internal identity store to change their own passwords. The UCP web service allows only the users 
to change their passwords. They can do so on the primary or secondary ACS servers.
The UCP web service compares the new password that you provide with the password policy that is configured in ACS 
for users. If the new password conforms to the defined criteria, your new password takes effect. After your password is 
changed on the primary ACS server, ACS replicates it to all the secondary ACS servers.
To download the UCP WSDL Files:
1.Choose System Administration > Downloads > User Change Password.
The User Change Password (UCP) web service page appears.
2.Click one of the following:
UCP WSDL to download the WSDL file.
UCP Web application example to download the application file.
Python Script for Using the User Change Password Web Service to download a sample Python script.
For more information on how to use the UCP web service, refer to Software Developer’s Guide for Cisco Secure 
Access Control System.
Downloading Sample Python Scripts
The Scripts page contains sample Python scripts for:
Using the UCP web service.
Automating the bulk import and export operations.
To download these sample scripts:
1.Choose System Administration > Downloads > Sample Python Scripts. 
						

							44
Managing System Administration Configurations
 
Available Downloads
The Sample Python Scripts page appears.
2.Click one of the following:
Python Script for Using the User Change Password Web Service—To download the sample script for the UCP web 
service.
Python Script for Performing CRUD Operations on ACS Objects—To download the sample script for the import and 
export process.
3.Save the script to your local hard drive.
The scripts come with installation instructions. For more information on how to use the scripts, refer to Software 
Developer’s Guide for Cisco Secure Access Control System. 
Note: The Cisco Technical Assistance Center (TAC) supports only the default Python Script. TAC does not offer any 
support for modified scripts.
Downloading Rest Services
ACS Rest Service allows to create, update, delete and retrieve objects from ACS Database.
Note: You must enable the Rest Service using the command line for reading the WADL files.
To download ACS Rest Service WADL files:
1.Choose System Administration > Downloads > Rest Service.
The Rest Service Page appears.
2.Click one of the following:
Common or Identity—To download XSD files that describe the structure of the objects supported on ACS 5.7 Rest 
interfaces.
Schema files—To download the Schema files.
SDK Samples—To download the SDK Samples.
For more information on how to use the Rest Services, refer to Software Developer’s Guide for Cisco Secure Access 
Control System. 
						

							1
Cisco Systems, Inc.www.cisco.com
 
Understanding Logging
This chapter describes logging functionality in ACS 5.7. Administrators and users use the various management interfaces 
of ACS to perform different tasks. Using the administrative access control feature, you can assign permissions to 
administrators and users to perform different tasks.
Apart from this, you also need an option to track the various actions performed by the administrators and users. ACS 
offers you several logs that you can use to track these actions and events.
This chapter contains the following sections:
About Logging, page 1
ACS 4.x Versus ACS 5.7 Logging, page 9
About Logging
You can gather the following logs in ACS: 
Customer Logs—For auditing and troubleshooting your ACS, including logs that record daily operations, such as 
accounting, auditing, and system-level diagnostics. 
Debug logs—Low-level text messages that you can export to Cisco technical support for evaluation and 
troubleshooting. You configure ACS debug logs, using the command line interface. Specifically, you enable and 
configure severity levels of the ACS debug logs using the command line interface. See Command Line Interface 
Reference Guide for Cisco Secure Access Control System 5.7 for more information.
Platform logs—Log files generated by the ACS appliance operating system.
Debug and platform logs are stored locally on each ACS server. Customer logs can be viewed centrally for all servers in 
a deployment.
You can use the following ACS interfaces for logging: 
Web interface—This is the primary logging interface. You can configure which messages to log and to where you 
want the messages logged.
Command line interface (CLI)—Allows you to display and download logs, debug logs, and debug backup logs to the 
local target. The CLI also allows you to display and download platform logs. See Command Line Interface Reference 
Guide for Cisco Secure Access Control System 5.7 for more information.
Using Log Targets
You can specify to send customer log information to multiple consumers or Log Targets and specify whether the log 
messages are stored locally in text format or forwarded to syslog servers. By default, a single predefined local Log Target 
called Local Store stores data in text format on an ACS server and contains log messages from the local ACS server only. 
You can view records stored in the Local Store from the CLI. 
In addition, you can specify that logs be forwarded to a syslog server. ACS uses syslog transport to forward logs to the 
Monitoring and Reports component. You can also define additional syslog servers to receive ACS log messages. For each 
additional syslog server you specify, you must define a remote log target.  
						

							2
Understanding Logging
 
About Logging
In a distributed deployment, you should designate one of the secondary ACS servers as the Monitoring and Reports 
server, and specify that it receive the logs from all servers in the deployment. By default, a Log Target called the 
LogCollector identifies the Monitoring and Reports server.
In cases where a distributed deployment is used, the Log Collector option on the web interface designates which server 
collects the log information. It is recommended that you designate a secondary server within the deployment to act as 
the Monitoring and Reports server.
This section contains the following topics:
Logging Categories, page 2
Log Message Severity Levels, page 4
Local Store Target, page 4
Viewing Log Messages, page 8
Debug Logs, page 9
Logging Categories
Each log is associated with a message code that is bundled with the logging categories according to the log message 
content. Logging categories help describe the content of the messages that they contain.
A logging category is a bundle of message codes which describe a function of ACS, a flow, or a use case. The categories 
are arranged in a hierarchical structure and used for logging configuration. Each category has:
Name—A descriptive name
Type—Audit, Accounting, or Diagnostics
Attribute list—A list of attributes that may be logged with messages associated with a category, if applicable
ACS provides these preconfigured global ACS logging categories, to which you can assign log targets (see Local Store 
Target, page 4):
Administrative and Operational audit, which can include:
—ACS configuration changes—Logs all configuration changes made to ACS. When an in item is added or edited, 
the configuration change events also include details of the attributes that were changed and their new values. 
If an edit request resulted in no attributes having new values, no configuration audit record is created.
Note: For complex configuration items or attributes, such as policy or DACL contents, the new attribute value is 
reported as "New/Updated" and the audit does not contain the actual attribute value or values.
—ACS administrator access—Logs all events that occur when an administrators accesses the system until the 
administrator logs out. It logs whether the administrator exits ACS with an explicit request or if the session has 
timed out. This log also includes login attempts that fail due to account inactivity. Login failures along with failure 
reasons are logged.
—ACS operational changes—Logs all operations requested by administrators, including promoting an ACS from 
your deployment as the primary, requesting a full replication, performing software downloads, doing a backup 
or restore, generating and restoring PACs, and so on.
—Internal user password change—Logs all changes made to internal user passwords across all management 
interfaces.
In addition, the administrative and operational audit messages must be logged to the local store. You can optionally 
log these messages to remote logging targets (see Local Store Target, page 4). 
						

							3   
Understanding Logging
About Logging
AAA audit, which can include RADIUS and TACACS+ successful or failed authentications, command-access passed 
or failed authentications, password changes, and RADIUS request responses.
AAA diagnostics, which can include authentication, authorization, and accounting information for RADIUS and 
TACACS+ diagnostic requests and RADIUS attributes requests, and identity store and authentication flow 
information. Logging these messages is optional.
System diagnostic, which can include system startup and system shutdown, replication failures, and logging-related 
diagnostic messages:
—Administration diagnostic messages related to the CLI and web interface
—External server-related messages
—Local database messages
—Local services messages
—Certificate related messages
Logging these messages is optional.
System statistics, which contains information on system performance and resource utilization. It includes data such 
as CPU and memory usage and process health and latency for handling requests.
Accounting, which can contain TACACS+ network access session start, stop, and update messages, as well as 
messages that are related to command accounting. In addition, you can log these messages to the local store. 
Logging these messages is optional.
The log messages can be contained in the logging categories as described in this topic, or they can be contained in the 
logging subcategories. You can configure each logging subcategory separately, and its configuration does not affect the 
parent category. 
In the ACS web interface, choose System Administration > Configuration > Logging Categories > Global to view the 
hierarchical structure of the logging categories and subcategories. In the web interface, choose Monitoring and Reports 
> Reports > ACS Reports to run reports based on your configured logging categories.
Each log message contains the following information:
Event code—A unique message code.
Logging category—Identifies the category to which a log message belongs.
Severity level—Identifies the level of severity for diagnostics. See Log Message Severity Levels, page 4 for more 
information.
Message class—Identifies groups of messages of similar context, for example, RADIUS, policy, or EAP-related 
context.
Message text—Brief English language explanatory text.
Description—English language text that describes log message reasons, troubleshooting information (if applicable), 
and external links for more information.
Failure reason (optional)—Indicates whether a log message is associated with a failure reason.
Passwords are not logged, encrypted or not. 
						

							4
Understanding Logging
 
About Logging
Global and Per-Instance Logging Categories 
By default, a single log category configuration applies to all servers in a deployment. For each log category, the threshold 
severity of messages to be logged, whether messages are to be logged to the local target, and the remote syslog targets 
to which the messages are to be sent to, are defined. 
The log categories are organized in a hierarchical structure so that any configuration changes you make to a parent 
category are applied to all the child categories. However, the administrator can apply different configurations to the 
individual servers in a deployment.
For example, you can apply more intensive diagnostic logging on one server in the deployment. The per-instance logging 
category configuration displays all servers in a deployment and indicates whether they are configured to utilize the global 
logging configuration or have their own custom configuration. 
To define a custom configuration for a server, you must first select the Override option, and then configure the specific 
log category definitions for that server. 
You can use the Log Message Catalog to display all possible log messages that can be generated, each with its 
corresponding category and severity. This information can be useful when configuring the logging category definitions.
Log Message Severity Levels
You can configure logs of a certain severity level, and higher, to be logged for a specific logging category and add this 
as a configuration element to further limit or expand the number of messages that you want to save, view, and export. 
For example, if you configure logs of severity level WARNING to be logged for a specific logging category, log messages 
for that logging category of severity level WARNING and those of a higher priority levels (ERROR and FATAL) are sent to 
any configured locations. Table 36 on page 4 describes the severity levels and their associated priority levels.
Local Store Target
Log messages in the local store are text files that are sent to one log file, located at /opt/CSCOacs/logs/localStore/, 
regardless of which logging category they belong to. The local store can only contain log messages from the local ACS 
node; the local store cannot accept log messages from other ACS nodes.
You can configure which logs are sent to the local store, but you cannot configure which attributes are sent with the log 
messages; all attributes are sent with sent log messages.
Administrative and operational audit log messages are always sent to the local store, and you can also send them to 
remote syslog server and Monitoring and Reports server targets.
Log messages are sent to the local store with this syslog message format:
Table 36 Log Message Severity Levels
ACS Severity 
LevelDescriptionSyslog Severity 
Level
FATAL Emergency. ACS is not usable and you must take action immediately. 1 (highest)
ERROR Critical or error conditions. 3
WARN Normal, but significant condition. 4
NOTICE Audit and accounting messages. Messages of severity NOTICE are always sent 
to the configured log targets and are not filtered, regardless of the specified 
severity threshold.5
INFO Diagnostic informational message. 6
DEBUG Diagnostic message. 7 
						

							5   
Understanding Logging
About Logging
time stamp sequence_num msg_code msg_sev msg_class msg_text attr=value
Table 37 on page 5 describes the content of the local store syslog message format.
You can use the web interface to configure the number of days to retain local store log files; however, the default setting 
is to purge data when it exceeds 5 MB or each day, whichever limit is first attained.
Table 37 Local Store and Syslog Message Format
Field Description
timestamp Date of the message generation, according to the local clock of the originating ACS, in the 
format YYYY- MM-DD hh:mm:ss:xxx +/-zh:zm. Possible values are:
YYYY = Numeric representation of the year.
MM = Numeric representation of the month. For single-digit months (1 to 9) a zero 
precedes the number.
DD = Numeric representation of the day of the month. For single-digit days (1 to 9), a 
zero 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.
xxx = The millisecond of the second—000 to 999.
+/-zz:zz = The time zone offset from the ACS server’s time zone, where zh is the 
number of offset hours and zm is the number of minutes of the offset hour, all of which 
is preceded by a minus or plus sign to indicate the direction of the offset. 
For example, +02:00 indicates that the message occurred at the time indicated by the 
t i m e  s t a m p ,  a n d  o n  a n  AC S  n o d e  t h a t  i s  t w o  h o u r s  a h e a d  o f  t h e  AC S  s e r ve r ’ s  t i m e  z o n e .
sequence_num Global counter of each message. If one message is sent to the local store and the the syslog 
server target, the counter increments by 2. Possible values are 0000000001 to 999999999.
msg_code Message code as defined in the logging categories.
msg_sev Message severity level of a log message (see Table 36 on page 4). 
msg_class Message class, which identifies groups of messages with the same context.
text_msg English language descriptive text message.
attr=value Set of attribute-value pairs that provides details about the logged event. A comma (,) 
separates each pair.
Attribute names are as defined in the ACS dictionaries.
Values of the Response direction AttributesSet are bundled to one attribute called 
Response and are enclosed in curly brackets {}. In addition, the attribute-value pairs within 
the Response are separated by semicolons. For example:
Response={RadiusPacketType=AccessAccept; AuthenticationResult=UnknownUser; 
cisco-av-pair=sga:security-group-tag=0000-00; } 
						

							6
Understanding Logging
 
About Logging
If you do configure more than one day to retain local store files and the data size of the combined files reaches 95000Mb, 
a FATAL message is sent to the system diagnostic log, and all logging to the local store is stopped until data is purged. 
Use the web interface to purge local store log files. Purging actions are logged to the current, active log file. See Deleting 
Local Log Data, page 27.
The current log file is named acsLocalStore.log. Older log files are named in the format 
acsLocalStore.log.YYYY-MM-DD-hh-mm-ss-xxx, where:
acsLocalStore.log = The prefix of a non-active local store log file, appended with the time stamp.
Note: The time stamp is added when the file is first created, and should match the time stamp of the first log 
message in the file.
—YYYY = Numeric representation of the year.
—MM = Numeric representation of the month. For single-digit months (1 to 9), a zero precedes the number.
—DD = Numeric representation of the day of the month. For single-digit days (1 to 9), a zero precedes the number.
—hh = Hour of the day—00 to 23.
—mm = Minute of the hour—00 to 59.
—ss = Second of the minute—00 to 59.
—xxx = Millisecond of the second—000 to 999.
You can configure the local store to be a critical log target. See Viewing Log Messages, page 8 for more information on 
critical log targets.
You can send log messages to the local log target (local store) or to up to eight remote log targets (on a remote syslog 
server):
Select System Administration > Configuration > Log Configuration > Remote Log Targets to configure remote 
log targets. 
Select System Administration > Configuration > Log Configuration > Logging Categories to configure which log 
messages you want to send to which targets. 
Critical Log Target
The local store target can function as a critical log target—the primary, or mandatory, log target for a logging category. 
For example, administrative and operational audit messages are always logged to the local store, but you can also 
configure them to be logged to a remote syslog server or the Monitoring and Reports server log target. However, 
administrative and operational audit messages configured to be additionally logged to a remote log target are only 
logged to that remote log target if they are first logged successfully to the local log target. 
When you configure a critical log target, and a message is sent to that critical log target, the message is also sent to the 
configured noncritical log target on a best-effort basis.
When you configure a critical log target, and a message does not log to that critical log target, the message is also 
not sent to the configured noncritical log. 
When you do not configure a critical log target, a message is sent to a configured noncritical log target on a 
best-effort basis.
Select System Administration > Configuration > Log Configuration > Logging Categories > Global > log_category, 
where log_category, is a specific logging category to configure the critical log target for the logging categories.
Note: Critical logging is applicable for accounting and AAA audit (passed authentications) categories only. You cannot 
configure critical logging for the following categories: AAA diagnostics, system diagnostics, and system statistics.