This document provides the best practices for administrating the Cisco
Secure (CS) ACS for UNIX application. The recommendations presented in this
document are based on design and deployment experiences by Cisco Development
The information in this document is based on these software and
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
Below is a listing of the recommended best practices.
Make sure that the SqlAnyWhere database does not exceed 5000 user
Accounting records should not exceed 50,000 records in the
Run the AcctExport utility daily.
If the transaction rate is very high, and there is huge accounting
traffic such that there are more than 50,000 accounting records, then run
AcctExport twice or thrice based on the load.
Make sure that there is adequate disk and Swap space available on
the Solaris box.
Run the dbunload utility monthly. This will help to reduce the size
of CSUnix Database.
The csecure.db should never exceed 1 GB of disk
If the csecure.db exceeds in size very quickly, then make sure that
dbunload is run more frequently.
If Radius AAA is not used in CS, then this can be disabled with the
help of –R flag in /etc/rc2.d/S80Ciscosecure.
At runtime, DBServer errors, including the errors encountered in
the interface to database, are reported in the logfiles/csdb_ <date>
file. Any unexpected errors or crash information by JAVA Virtual Machine are
logged in log/dbserver.log file. Check these files for any
If the AAAServer crashes, the core files will be located in the
$BASEDIR/corefiles. Check for the existence of core files, if
Backup the database regularly (daily or weekly), based on the
For better performance, disable the csuslog logging feature. This
will drastically increase the performance.
The ulimit value should be 4096 in /etc/system,
Remove the csecure.log regularly. Before removing the csecure.log,
CS should be stopped.
Do not manually add/modify/delete the database/ tables directly -
use only the supported methods.
Archive the $BASEDir/logfiles directory once a
Archive /var/log/csuslog files regularly, and trim the size by
issuing the command cat /dev/null > csuslog. If
the file is deleted, syslog will not work, and hence the log will not be
redirected to the csuslog file.
DNS Server Issues: If the target system has a DNS configured, or if
the Solaris operating system has been configured as a DNS server, special care
must be taken to insure that DNS performance and operations are fully
If the CS ACS server target Solaris system has DNS enabled, there
might be performance or authentication issues for CS ACS. CS ACS does not
directly call a DNS server; however, the Solaris operating system calls
“gethostbyadd_r” and might indirectly call the DNS server, if configured to do
so. Check the /etc/nsswitch.conf file for such a configuration. If the DNS
domain name resolution operation does not work or is slow, this directly
affects CS ACS.
While running tools such as dbbackup and dbunload, the PATH should
be correctly set. Otherwise, the tools may not work properly.
$BASEDIR/utils/bin/env_setup can be used for setting the path. This file
contains all of the required environmental variables and other path
The MaxConnection and ConnectionLicense parameters should be set so
as to meet the needs based on the number of authentications and the number of
Transactions that the CSU can handle. MaxConnection can be set to a max value
of 50, if the db used is SqlAnyWhere. Increase the ConnectionLicense in
$BASEDIR/config/CSConfig.ini, and correspondingly increase the value of
MaxConnection in $BASEDIR/CSU/libdb.conf to a value two less than the
ConnectionLicense based on the load.
When using automated scripts to log in to routers and switches, and
execute commands, it is a good practice to place
sleep commands in between regular router/switch
commands. This helps spread the load and avoid resource contentions in the CS
Further, these automated scripts should properly close Telnet
sessions (even in the case of any command failures) to ensure resources are not
locked at the CS server.