|
|
This document provides new information about CiscoSecure Acess Control Server (ACS) 2.2.2 for UNIX that became available after the CiscoSecure ACS 2.2.2 for UNIX User Guide was prepared. This document includes:
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more up to date than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
This section lists and describes the latest information about this version of the CiscoSecure ACS 2.2 for UNIX software. Information is updated immediately prior to release of the software.
The CiscoSecure ACS startup process has been enhanced to autorestart the CiscoSecure ACS if its AAA or DBServer components abnormally abort. To provide this functionality, a new process, "CiscoAuto," is started during CiscoSecure startup. If the AAA or DBServer component aborts, CiscoAuto detects this event and performs a CiscoSecure restart. During this process, the following events occur:
1 ) The CiscoSecure ACS is shut down.
2 ) Any core files in the CSU or DBServer directories are moved to $BASEDIR/corefiles and compressed.
3 ) The CiscoSecure ACS is restarted.
The AutoRestart feature can be customized or disabled by specifying several command-line switches with the S80CiscoSecure startup command. The switches are as follows:
The conversion utility, cnv, allows you to import a public domain TACACS+ freeware database into a CiscoSecure ACS 2.x for UNIX database. With cnv, the user can create an intermediate file (import file) that can then be imported in CiscoSecure 2.x RDBMS using CSImport.
However, before the import file can be used, it must be broken into two files. The first section of the import file contains the AAA server control file; the second part contains all the user profiles to import. The import file contains a separator bar, separating these two sections. Command-line syntax for cnv is as follows:
cnv <old_Config >new_Config
where
To create an import file from a TACACS+ freeware configuration file named "myoldconfigfile," the system administrator would follow these steps.
Step 1 Type: cnv <myoldconfigfile>mynewimportfile
Step 2 Break mynewimprofile into AAA.cnf and newuser.dat. AAA.cnf contains the AAA server configuration information and newuser.dat contains the user profiles to add to the RDBMS.
Step 3 Run CSimport to import the user profiles.
CSimport -c -p /dir -s newuser.dat
Step 4 Update CSU.cfg with the appropriate AAA server information contained in AAA.cnf.
CiscoSecure ACS support for token card-generated, one-time password (OTP) logins requires the host network access server (NAS) to be configured with a minimum 10-second TACACS+ timeout setting:
tacacs-server timeout 10
The default setting of one second will cause OTP logins to fail a large percentage of the time.
You can edit the CSConfig.ini file to restrict administrative access to the CiscoSecure ACS administration web pages and command-line interface (CLI) to a specified list of workstations that you have assigned IDs to.
Step 1 Locate the CSConfig.ini file in the $BASEDIR/config directory of the CiscoSecure ACS 2.2.2 installation.
Step 2 Insert or edit the following lines to the [ValidClients] section of the CSConfig.ini file:
[ValidClients]
ID_num = my_wrk_station
ValidateClients = {true|false}
where:
Step 3 After editing the CSConfig.ini file, restart the CiscoSecure ACS to apply the changes.
In the following example:
[ValidClients] 100 = ws-barrylee 120 = ws-pameagan ValidateClients = true
two workstations, with the FQDNs of ws-barrylee and ws-pameagan, are authorized to access the CiscoSecure administration tools. The setting ValidateClients = true stops any workstation not specifically listed in the [ValidClients] section from accessing the CiscoSecure ACS web pages or CLI.
In the following example:
[ValidClients] 100 = ws-barrylee 120 = ws-pameagan ValidateClients = false
the setting ValidateClients = false allows any workstation to access the CiscoSecure ACS web pages or the CLI, whether or not it is specifically listed in the [ValidClients] section.
If your NASes are running the Cisco IOS release 11.3 or higher, and you want to support CiscoSecure authorization of users who are dialing in over multiple ISDN channels, use the Java-based CiscoSecure Administrator advanced configuration program to add the protocol = multilink attribute-value to the profiles of the affected users.
CiscoSecure ACS 2.2.2 provides a new command switch, -prv, for the CLI AddProfile command.
In contrast to the existing -pw switch, which enables you to specify password type and password, the new -prv switch enables you to specify password type, password, and privilege-level requirements, if necessary, to new user profiles. The new syntax for the AddProfile command is:
AddProfile [-h host] -p port [-id client] {-u user | -g group} [-pr parent-group] [-pw password-pair] [-prv password-trio] [-a profile-info] [-q]
In the AddProfile command syntax, the -pw and -prv switches are mutually exclusive. Use the -pw switch when creating profiles with passwords but no privilege-level requirements; use the -prv switch when creating profiles with password and privilege-level requirements.
The following table describes and contrasts the -pw and -prv switches.
| Switch | Command Type | Description |
|---|---|---|
| -pw | password pair (optional)
type, password or type | Defines which passwords to add to the user's profile.
-pw ARAP,2sAmzpwRd
-pw SDI |
| -prv | password trio (optional)
type, password or type, privilege level | Defines which password and privilege level requirement (if necessary) to add to the user's profile.
-prv clear,2sAmzpwRd,13
-prv SDI,13 |
New variables have been defined for the CiscoSecure CSU.cfg file. These variables are in addition to the variables described in the appendix, "CiscoSecure ACS File Formats and Syntax" in the CiscoSecure ACS 2.2.2 for UNIX User Guide.
| Type | Name | Default | Description & Example |
|---|---|---|---|
| String | config_acct_filename | /var/log /CSAccountingLog | The file where accounting records are stored in case of database failure.
Example: STRING config_acct_filename = "/spec/Acct";
|
| Number | config_metrics_enable | 0 (disable) | Whether to enable or disable AAA server metrics monitoring. This feature records AAA server performance statistics (such as transactions per second, total authentications) in the csuslog file.
1 = enable; 0 = disable Example: NUMBER config_metrics_enable = 1; For a description of the AAA server metrics, see "Reading AAA Server Metrics Information in the csuslog File," page 12. See the config_metrics_log_interval description for other related information. Important: AAA server metrics information can cause the csuslog file to grow extremely large. Cisco recommends enabling this feature only for short periods of time. |
| Number | config_metrics_log_interval | 8 (seconds) | Number of seconds between the AAA metrics updates to the csuslog file. See the config_metrics_enable description in this table for related information.
Example: NUMBER config_metrics_log_interval = 10;
|
| Number | config_callerid_enable | 1 (enable) | Whether to enable or disable the use of the caller ID as a username when a username cannot be found. If the caller ID support feature is not required, Cisco recommends disabling it to improve authentication performance.
1 = enable; 0 = disable Example: NUMBER config_callerid_enable = 0; For details on caller ID support, see "Using New Support for Caller ID," page 15. |
| Number | config_defaultuser_enable | 1 (enable) | Whether to enable or disable use of the default user profile if the user/callerID can't be found . If the default user/caller ID support feature is not required, Cisco recommends disabling it to improve authentication performance.
1 = enable; 0 = disable Example: NUMBER config_defaultuser_enable = 0;
|
| Number | config_maxsessions_enable | 0 (disable) | Whether to enable or disable the AAA server implementation of a group or user profile's "server max-sessions" attribute.
1 = enable; 0 = disable Example: NUMBER config_maxsessions_enable = 1; Important: See the section, "Limiting Sessions Per User," page 8, before setting this variable. |
| Number | config_maxsessions_session_timeout | 1440 (minutes)
| Number of minutes after which a session will be considered closed by the CiscoSecure max sessions counter. The purpose of this variable is to remove from the max sessions count sessions that should be timed out, but that, for some reason, have not been noted as closed or decremented by the max session counter. It does not actually enforce closure of the session in the NAS.
Example: NUMBER config_maxsessions_session_timeout = 60; Important: See the section, "Limiting Sessions Per User," page 8, before setting this variable. |
| Number | config_maxsessions_purge_ interval | 60 (minutes)
| Interval in minutes between checking the possible timeout of sessions for the purpose of updating the max sessions counter.
Example: NUMBER config_maxsessions_purge_interval = 90; Important: See the section, "Limiting Sessions Per User," page 8, before setting this variable. |
| Number | config_acct_fn_enable | 1 (enable) | Whether to enable or disable inclusion of per user group membership information in an accounting record if a user profile has the "accounting feature" attribute added.
When this function is disabled, an accounting record for a user session will not insert group information in the accounting record. 1 = enable; 0 = disable Example: NUMBER config_acct_fn_enable = 0; For details on the accounting feature attribute and group membership accounting information, see the chapter, "CiscoSecure ACS Accounting" in the CiscoSecure ACS 2.2.2 for UNIX User Guide. |
To improve authentication performance, you can set some of the CSU.cfg variables described in the section "New CSU.cfg Variables" to disabled status if the feature they toggle is not required for your operation. Disabling unneeded optional features improves authentication performance by stopping processes that require additional system time.
The following variables can be set to disable (for example: config_maxsessions_enable = 0 ) if you do not require the feature that they toggle on and off:
For any of these listed variables, check the description in "New CSU.cfg Variables," page 6 to decide whether you need the feature they enable or not. For additional information on config_maxsessions_enable, see also "Limiting Sessions Per User," page 8.
The CiscoSecure max-sessions feature enables you to limit the number of sessions that an individual CiscoSecure user can open concurrently. This feature prevents any one user from appropriating a disproportionate number of available sessions, and prevents multiple users from using one paid username to get multiple free sessions.
Using the Java-based CiscoSecure Administrator advanced configuration program, you can apply the special CiscoSecure server max-sessions attribute to a group profile or user profile and then tune the feature for performance or reliability, or disable it by editing the CSU.cfg and CSConfig.ini files.
Assign the max-sessions attribute as follows:
Step 1 Start the Java-based CiscoSecure Administrator advanced configuration program.
Step 2 In the Members tab, deselect browse, select the group or user profile that you want to apply the max-session limitation to, and click the profile icon to display its Options menu.
Step 3 In the Options menu, select Profile attributes and click Apply to display the Profile attributes icon.
Step 4 Click the Profile attributes icon to display its Options menu, and in the Options menu, click server max-sessions.
Step 5 In the Numeric value field, enter the max-sessions number that you want to apply. For example:
3
Step 6 Click Apply, then click Submit.
Step 7 In the server's $BASEDIR/config directory, edit the CSU.cfg and CSConfig.ini files to enable and tune the max-sessions feature to meet your particular requirements.
If you want the highest-performance max session checking, configure max sessions to be executed by the CiscoSecure AAA server module. Edit the CSU.cfg and CSConfig.ini files as follows:
Step 1 In the CSU.cfg file, make sure the following variables are set:
session_minutes
purge_interval_minutes
where:
Step 2 In the CSConfig.ini file, make sure the following parameters are set in the [AccountingMgr] section:
Step 3 In order to implement the CSConfig.ini edits, restart the CiscoSecure ACS.
Under this configuration, the session count for your users whose profile is assigned a server max-session attribute will be maintained and enforced; however, if CiscoSecure is disrupted and restarted for any reason, the session count for those users will be reset to 0.
If you want highly persistent max-sessions checking, configure the max-sessions feature to be carried out by the CiscoSecure DBServer module. This configuration preserves the current max-sessions count of your users in event of a CiscoSecure shutdown. Edit the CSU.cfg and CSConfig.ini files as follows.
Step 1 In the CSU.cfg file, make sure the following variables are set:
Step 2 In the CSConfig.ini file, make sure the following parameters are set in the [AccountingMgr] section:
purge_interval_minutes
session_minutes
where:
AcctPurgeInterval = 75
Step 3 In order to implement the CSConfig.ini edits, restart the CiscoSecure ACS.
Under this configuration, the session count for your users whose profile is assigned a server max-session attribute will be maintained and enforced; if CiscoSecure is disrupted and restarted, the session count for those users will be preserved and restored when CiscoSecure is restarted.
To disable max-session checking without deleting the server max-session attribute from each profile, edit the CSU.cfg and CSConfig.ini files as follows:
Step 1 In the CSU.cfg file, make sure that the following variable is set:
Step 2 In the CSConfig.ini file make sure the following parameters are set in the [AccountingMgr] section:
Step 3 To implement the CSConfig.ini edits, restart the CiscoSecure ACS.
AAA server metrics information in the csuslog file is generated when the enable_config_metrics variable is toggled on and the config_metrics_log_interval variable is set in the CSU.cfg file.
Typical AAA metric data output to a csuslog file, is shown below:
Mar 9 06:11:33 srv1 Total Authentications = 3176 APS = 0.0 Mar 9 06:11:33 srv1 TotalReqs TotalSec Mar 9 06:11:33 srv1 Accounting 3164 901.85 Mar 9 06:11:33 srv1 MaxSessions 3176 463.81 Mar 9 06:11:34 srv1 Profile 2974 248.26
Each log entry line displays the date and time of the entry and the name of the AAA server doing the processing. Other values displayed include:
Occasionally messages indicating "Severe SQL Error" may appear in the CiscoSecure ACS 2.2.2 Administration web pages. The accompanying on-line help may direct you to view the DBServer log files. Two types of DBServer log files are located in the $BASEDIR/logfiles directory:
The csdblog_date log file, located in the $BASEDIR/logfiles directory, logs error and warning messages from both the DBServer module and from the RDBMS (Oracle, Sybase, or SQLAnywhere) where you are storing your group and user profiles. A new csdblog_date log file is created every day.
Sample output is as follows for csdblog_98-Mar-5 (note that the first two lines are always present even if nothing else is; the other lines are the result of errors):
/*** Cisco Secure database server error log ***/
SEVERITY LEVELS ranges from 1 to 10 where 1=MINOR, 10=CATASTROPHIC
----------------------------------------------------------------------------
Thu Mar 05 09:33:07 PST 1998 Severity Level: 8 Error#0
Msg:DBInterface.execSqlUpdate:[insert into cs_user_profile ( user_na
me, profile_id, profile_ts, cycle_number ) values ( ?, 100000001, ?, 1 )
]{ SQLState: }, { Message: ORA-23326: object group MASTER-
MASTER is quiesced}, { Vendor Code: 23326}
Thu Mar 05 09:33:07 PST 1998 Severity Level: 8 Error#0
Msg:DBInterface.execSqlsInTran:{ SQLState: }, { Message: ORA-23326:
object group MASTER-MASTER is quiesced}, { Vendor Code: 23326}
Thu Mar 05 09:33:08 PST 1998 Severity Level: 8 Error#0
Msg:DatabaseWorker error: ORA-23326: object group MASTER-MASTER is q
uiesced
An example of a common DBServer-generated message that might appear in a csdblog_date log file, is:
Wed Mar 04 12:51:49 PST 1998 Severity Level: 8 Error#0 Msg:DatabaseMgr:getAvailDBconn(): "Out of database resources error: The number of available connections to the Database has currently been reached. Please retry later"
If the preceding message appears frequently in the csdblog_date log file, increase the number of connections to the RDBMS or reduce the MaxConnection parameter in the CSU/libdb.conf file.
The DBServer module or RDBMS error messages that can be logged in a csdblog_date log file are ranked in order of severity from 1 to 10 (where: 1 = minor, 5 = moderate, 8 = severe, and 10 = catastrophic).
The default logging level is 8, which means that DBServer or RDBMS error messages with a severity of 8 or higher are logged in this file.
To change the level of logging for the purposes of troubleshooting or testing, edit the MinLogLevel = parameter in the $BASEDIR/config/CSConfig.ini file. For example, the following setting:
MinLogLevel = 5
enables logging in the csdblog_date log file of moderate-or-higher severity messages. Lowering the logging level increases the amount of messages written to your daily csdblog_date log files.
Major DBServer module events, such as startup or shutdown, are recorded in the DBServer.log file, located in the $BASEDIR/logfiles directory. DBServer events too sudden and catastrophic to be logged in the csdblog_date log file, might be recorded in the DBServer.log file.
If you change the default value of the Netscape FastTrack Server TCP/IP port number from 80 to some other value, you must perform the following additional steps to ensure continued operation of the Java-based CiscoSecure Administrator advanced configuration program.
Step 1 On the CiscoSecure ACS server, locate the $BASE/FastAdmin/turbo.conf file and change the following line:
NS_PATH=machine_name/cs/
to
NS_PATH=machine_name:new_port_num/cs/
Where:
For example:
NS_PATH=rtp-evergreen:8080/cs/
Step 2 Locate the $BASEDIR/ns-home/httpd-hostname/config/magnus.conf file and change the following line:
to
Port new_port_num
where: new_port_num is the new TCP/IP port value.
To protect data transfers (which can include passwords) between the CiscoSecure ACS graphical user interface (GUI) and your web browser, enable the Secure Socket Layer (SSL) protocol. SSL is a security protocol created by Netscape Communications Corporation. This protocol ensures that data is encrypted before being transferred over the network.
CiscoSecure ACS software provides security for remote access, and SSL provides security for data transfer between the Netscape FastTrack web server and browser.
The CiscoSecure ACS GUI communicates with the Netscape FastTrack web server, and the web server in turn communicates with the CiscoSecure ACS database. By employing CiscoSecure ACS and enabling SSL, you can provide secure data transfer into and within your network.
SSL works by requiring Netscape Navigator to authenticate only a server that has a key that is signed by either Netscape or VeriSign. VeriSign will sign your keys for a fee, provided you comply with certain requirements.
To enable SSL on your web server, follow these steps:
Step 1 Log in to the FastTrack Server as the administrator (root privileges). Enter:
You are prompted for a username and password.
Step 2 Enter the username and password, for example:
The Netscape Server Selector window opens.
Step 3 Click the name of your Netscape FastTrack Server.
Step 4 From the command buttons at the top of the window, click Encryption.
Step 5 On the left side of the window, click Generate Key.
A help window called Generating a key pair opens.
Step 6 Follow the online instructions to generate a server key pair.
Step 7 Click Request Certificate.
The online form called Request a Server Certificate opens.
Step 8 Complete the online form, then click OK.
Step 9 Request a certificate from a Certification Authority (such as VeriSign at www.verisign.com) and obtain a signed key.
Step 10 When you receive the server certificate, click Install Certificate from the Server Manager window.
The online form called Install a Server Certificate opens.
Step 11 Complete the online form, then click OK to install the server certificate.
Step 12 On the left side of the window, click On/Off to enable encryption.
New TACACS+ and RADIUS support for caller ID allows you to base profiles on the calling number, rather than the username being passed. Identifying users by their telephone number is especially useful for accounting purposes because you can directly bill charges according to the calling number.
To configure support for caller ID, create a new user profile and enter a designated telephone number instead of a username.
The following example shows a user profile configured for caller ID:
user =5551212password =chap01
In this case, if an unknown user dials into the network access server (NAS), the NAS passes the user's information including "rem_addr (5551212)" to the CiscoSecure ACS. The CiscoSecure ACS first attempts to authenticate the user based on the user field, but in this case, the user is not in the CiscoSecure database. However, because the user profile contains the caller ID, the CiscoSecure ACS uses the rem_addr (5551212) to index into the database.
For more information on tuning this the caller ID feature, see the descriptions of the CSU.cfg variables, config_callerid_enable and config_defaultuser_enable in "New CSU.cfg Variables," page 6.
The profile attribute Privilege - Web will accept a blank password (input as a blank space in the password field) as valid.
Use the following procedures to increase GUI performance on Netscape Navigator browser.
Step 1 Bring up the Netscape Navigator Cache settings.
The Memory Cache dialog box opens.
Step 2 In the Memory Cache field, increase the number from the default (1024 kilobytes) to 8000.
Step 3 In the Disk Cache field, increase the number the default (5000 kilobytes) to 20000.
Step 4 Click OK.
The increased memory and disk cache take effect immediately.
Step 1 Bring up the Netscape Navigator Cache settings.
The Memory Cache dialog box opens.
Step 2 Click Clear Memory Cache Now.
Step 3 Click Clear Disk Cache Now.
Step 4 Click OK.
The memory and disk cache are cleared immediately.
The CiscoSecure ACS now enables you to set up the profiles of one-time password (OTP) card users who use PPP and PAP protocols so that they can log in using a more conventional looking username and OTP entry than was previously required.
Previously, as documented in "Authenticating One Time Password Cards via PPP" in the chapter titled, "Token Server Support" in the CiscoSecure ACS 2.2.2 for UNIX User Guide, users assigned TACACS+ Service-PPP attribute, Password-PAP attribute, and an OTP password attribute (such as Password-Crypto, Password-Enigma, Password-SDI, Password-SKey, Password-DES) logged in by entering their username, an asterisk, and their OTP at the username prompt for example:
username:pameagan*546323
It is now possible, however, to assign TACACS+ or Cisco-RADIUS attributes in such a way as to enable PPP and PAP protocol OTP users to log in with more convention entries, entering username at the username prompt and entering the OTP at the password prompt. for example:
username:pameaganpassword:546323
Using the Java-based CiscoSecure Administrator advanced configuration program, configure your PPP and PAP protocol OTP users with either TACACS+ attributes or a combination of TACACS+ and Cisco-RADIUS attributes.
When running the administration GUI under Netscape Navigator, the virtual memory used by Netscape constantly increases. There are no known issues associated with this behavior.
The security of your network can be compromised in many ways beyond the data exchange between the NAS and the CiscoSecure ACS. This section identifies areas that are potential security hazards and gives you advice on what you can do to protect these key areas, or security holes, against potential intruders.
Keep your CiscoSecure server and NASes in a locked room. Restrict access to that room and the servers within it.
Unless physically protected, intruders can attack your network at several points. Perhaps most damaging is the possibility that an intruder can approach a security server and remove its disk drive for later analysis. Additionally, when security servers are physically accessible, intruders can potentially boot the server from a CD or floppy disk, then mount the hard disk from the system, and finally change the root password. With a new root password known only to the intruder, the potential for damage is limitless.
In other cases, the intruder might disrupt service by turning off the server or disconnecting it from the network. A "denial of service" attack might even involve destroying the security server or its disk; this is another scenario where keeping good backups can reduce downtime.
If at all possible, keep the local telephone closet locked. When the telephone lines going into a NAS are adequately secured, wire-tapping of telephone lines or monitoring of keystrokes becomes difficult (although not impossible).
Keep remote access to security servers as restricted as possible. Even with security servers physically locked down, attacks can be launched remotely by intruders if they can access the servers through the network. Many software bugs have eventually turned out to be security holes. For this reason, you should avoid using any unnecessary services on the security server that might potentially have as-yet-unknown security holes.
Most networks have large numbers of unencrypted passwords and other data flowing over them. As such, local users are able to "snoop," or easily extract, data flowing over broadcast technology networks such as Ethernet. At the very least, consider using secure methods of logging in and manipulating security configurations (for example, use Kerberized and encrypted rlogin access, SSL browsers, or dedicated and physically secured serial lines).
Do not allow local users to access security servers, even if the local users lack any privileges to change the configurations. This helps prevent exploitation of potential security holes that might exist but are generally not known.
Construct passwords that are fairly long (at least 8 characters) and consist of letters (uppercase and lowercase) and numbers. Confirm that the password cannot be easily guessed by people with familiarity with the local organization or personnel. Password-guessing attacks are the easiest and most common type of network intrusion. The easier a password is to guess, the faster an attacker can gain access to protected data.
Even well-chosen passwords are easily captured if sent in cleartext over broadcast media (such as Ethernet). Normally, protocols such as Telnet and rlogin do not encrypt passwords that are sent over the network although the destination system might encrypt those passwords upon arrival.
Use different passwords for the security servers and other systems, especially ones that can be accessed through unencrypted protocols. Some protocols, such as Kerberized Telnet, do not send the password over the network in cleartext, but subsequent data is still unencrypted. Consequently, while these protocols limit exposure, they do not entirely restrict exposure.
Confirm that your installation of CiscoSecure ACS is conducted in one session. Do not interrupt the installation. Similarly, do not leave your server unattended if you are conducting subsequent configurations, such as adding new users or support for a new one-time password card. An intruder can potentially gain sensitive information during configurations and use the information later.
Do not install CiscoSecure ACS over an unsecure network; instead, install CiscoSecure ACS at the system console.
When providing configuration information to anyone (even technical support personnel), remove sensitive information such as passwords. Replace sensitive information such as password strings with "XXXXXX."
Do not use the Netscape FastTrack Server software (which came bundled with CiscoSecure ACS) to serve any web pages that are not part of CiscoSecure ACS.
Use SSL for encrypted connections to the Netscape FastTrack Server. This provides a high degree of security. Users can use their own web browsers to connect to the CiscoSecure ACS database to change their own passwords. As such, all of the data traffic is vulnerable and should be encrypted.
This section identifies issues with CiscoSecure ACS 2.2.2 and related information. Some of these issues will be addressed in a subsequent release.
Cisco does not recommend that large enterprise or large ISP customers, who anticipate rapid growth and scaling up operations in the number of users, use the default SQLAnywhere CiscoSecure installation option as the RDBMS engine to support your users. Please note the following limitations of the SQLAnywhere RDBMS engine:
For customers who plan to carryout large scale database growth and update operations, Cisco recommends use of the Oracle Enterprise or Sybase Enterprise RDBMS engines.
The following issues have been reported when administering the CiscoSecure ACS through the Microsoft Internet Explorer 4.0 web browser. If you experience either issue, upgrade to Microsoft Internet Explorer 4.01 or use Netscape Navigator 3.04 or 4.04.
The following issues haven been reported when administering the CiscoSecure ACS through the Microsoft Internet Explorer 3.02 web browser. To remedy the following issues, upgrade to Microsoft Internet Explorer 4.01 or use Netscape Navigator 3.04 or 4.04.
The Security Socket Layer (SSL) feature of the Navigator 4 for Solaris browser does not support the Java-based CiscoSecure Administrator advanced configuration program. To access the CiscoSecure Administrator using the SSL feature, do so through Netscape Navigator or Netscape Communicator for Windows 95 or Windows NT. [CSCdj68773]
Although the CiscoSecure ACS Administration web pages allow the administrator to create a user profile simultaneously in the CiscoSecure ACS database and in the SafeWord (Enigma Logic) database, the administrator cannot use the CiscoSecure ACS Administration web pages to directly delete that same user profile from the SafeWord database.
This limitation exists because the SafeWord programmer interface to the SafeWord profile database does not allow external programs such as the CiscoSecure ACS Administration web pages to delete users.
The workaround is to use the CiscoSecure ACS Administration web pages to delete SafeWord users from the CiscoSecure ACS database and use the tools that SafeWord supplies to delete the same user from the SafeWord profile database. [CSCdj46835]
The authentication methodology used by the OTP cards from Security Dynamics, Inc. (SDI) differs somewhat from that used by the CiscoSecure ACS. Whereas SDI authentication uses a single process, CiscoSecure ACS employs a multithreaded approach for improved performance. Although not seen in either a laboratory or a beta site, a large volume of simultaneous SDI-based authentications can theoretically generate unexpected failures. In this case, the authentication might fail even though the username and password are correct. If users encounter this issue, advise them to wait a few moments, and then retry the operation. [CSCdj01541]
The Ascend-RADIUS dictionary supplied with CiscoSecure ACS 2.2 for UNIX requires the following updating and correction:
The Cisco-RADIUS dictionary supplied with CiscoSecure ACS 2.2 for UNIX does not include the most recently added attribute-value pairs that are supported in Cisco IOS release 11.3. If you require support of the latest attribute-value pairs, use the Dictionaries tab of the Java-based CiscoSecure Administrator advanced configuration program to add these attribute-value pairs to a customized version of the Cisco-RADIUS dictionary. [CSCdj60995]
Under certain circumstances, the Java-Based CiscoSecure Administrator advanced configuration program might fail to start and display a misleading error message as to the cause. If the CiscoSecure Administrator fails to start and displays the following message:
Server: Packet session identifier invalid
the issue might actually be blocked access to the CiscoSecure DBServer module's TCP/IP port 9900. Check the connection to the DBServer port 9900. Make sure that the DBServer module is loaded and running. Make sure that access to the DBServer port 9900 is not being blocked by a firewall. If it is, enable port 9900 on the firewall. [CSCdj72692]
The Java-based CiscoSecure Administrator advanced configuration program might fail to access user group profiles containing large numbers of users (approximately 10,000 or more) and display the following error message:
Applet CSAdmin java.lang.OutOfMemoryError
To avoid this issue, limit the size of user group files to 5,000 or less. If large user group profiles are necessary, you can manage them through the CiscoSecure Command-Line Interface. [CSCdj72212]
Depending on the size of your database and the number of client/server transactions taking place, you might experience some processing delays, such as waiting a long time for GUI screens to refresh. Although these GUI performance issues can be annoying, they do not result in system malfunction or loss of data.
Unlike other GUI-based applications that run locally on a given computer, CiscoSecure ACS is a network-based application and is therefore dependent on external data-transfer rates, such as what is provided by local telephone services. In addition, CiscoSecure ACS is a client/server product that includes a full relational database management system, so you might experience wait time as profiles are written to and from the database.
To change the username and password on your FastTrack Server, perform the following steps:
Step 1 Log in to FastTrack as the administrator:
http://name of your CiscoSecure Server:64000
You see a screen requesting your username and password.
Step 2 Enter your administrator username and password to gain access to the Web Server Administration section.
Step 3 Click the Configure Administration box.
Step 4 Click the Access Control line.
Editable fields for username and password display.
Step 5 Replace the username and password as necessary.
In cases where Oracle Master-to-Master or Sybase Peer-to-Peer database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same time period between database replication processes.
If updating of the same user profile at two different sites within the same time period between replications occurs, the user profile edits at neither site will be replicated or reconciled. The user profile will remain with unreconciled settings at both sites.
For more information, see "Precautions Running Oracle Database Replication and CiscoSecure," page 37 or "Precautions Running Sybase Database Replication and CiscoSecure," page 45. [CSCdj79568]
In cases where Oracle Master-to-Master (or Master-to-Updateable-Snapshot) database replication has been implemented, precautions need to be taken to minimize the chance of a CiscoSecure user attempting a failed login at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.
If failed logins under the same user profile occur at two different sites within the same interval between replications, the next time replication is run, Oracle shows a Unique Constraint error due to both profiles having the same name but different profile ID's.
When the same user subsequently attempts to log in, that user will fail due to the user account being locked.
The Database Administrator must delete one of the user's conflicting profiles at one of the sites and force replication before the user account can be reset.
To minimize the possibility of failed login of the same user at two or more sites within the same interval between replications:
CiscoSecure ACS installations using versions 7.3.3 and 7.3.2 of the Oracle client modules SQL*Net and TCP/IP protocol adapter sometimes experience profile retrieval and DBServer module failure problems under heavy usage. To forestall these problems, install the SQL*Net and TCP/IP protocol adapter client modules that come with Oracle 7.3.4 or higher.
The Oracle 7.3.4 upgrade is available free to all customers with a valid support contract. [CSCdj78312] [CSCdj86330]
Failure to maintain sufficient available disk space on the SQLAnywhere, Oracle, or Sybase database server storing records for the CiscoSecure ACS can result in a general warning message and a failure to update CiscoSecure accounting records. To prevent such failures, the system administrator should:
When the Oracle trace file exceeds 5 MB (as may happen under frequent and heavy loads), the Oracle server might occasionally dump core data and abort. This is a known Oracle problem (ID Number: 510778) that is remedied with Oracle version 8.0.4.
If this condition is causing problems, Oracle recommends that you disable Oracle tracing as follows:
Step 1 Go to the $ORACLE_HOME/otrace/admin directory of your Oracle server.
Step 2 Delete the existing process.dat and regid.dat files and recreate them to the default size.
otrccef
Step 3 Edit the Oracle user's shell startup file. For Bourne or Korn shell users the settings to add or edit are:
EPC_DISABLED=TRUE; export EPC_DISABLED
Step 4 Stop and restart the Oracle server. [CSCdj85981]
This section addresses errors in the CiscoSecure ACS 2.2.2 for UNIX User Guide and information that was not available before the user guide was printed.
The following information supplements the copyright information in the user guide:
CiscoSecure ACS 2.2.2 supports asynchronous database replication among multiple CiscoSecure ACS sites that use the Oracle 7.3.3 and later or Sybase 11.02 and later database engines to store their profile information. Two recommended database replication scenarios are:
This appendix provides example procedures for setting up Oracle and Sybase database systems to carry out replication of the CiscoSecure database among multiple CiscoSecure ACS sites.
Figure 1 illustrates an example of Master-to-Snapshot or Primary-to-Replicate database replication as applied to multiple CiscoSecure ACS sites. In this scenario all administrative changes to the user profile database are made through the web-based console to one ACS site. Then, at specified time intervals, those changes are replicated to all other sites on the network, enabling the ACSes to provide their authentication, authorization, and accounting services based on a common set of user profile data.
Figure 2 illustrates Master-to-Master or Peer-to-Peer database replication as applied to multiple CiscoSecure profile database sites. In this scenario, local administrative changes to the user profile database can be made through the web-based consoles at two or more ACS peer sites. Then, at specified time intervals, each of these peer sites communicate their local changes to all other sites on the network. As with Master-to-Snapshot replication, the end result is that the ACSes are able to provide their authentication, authorization, and accounting services based on a common set of user profile data.
The example procedures in this section use the Oracle Net8 Easy Config (or the Oracle 7 SQL Net Easy Config), Security Manager, Schema Manager, SQL*Plus, and Replication Manager programs run on a Windows 95 workstation console to integrate Oracle database replication with multiple CiscoSecure ACSes.
Caution Implementing Oracle database replication requires an in-depth knowledge of Oracle tools and database structure. Integrating database replication with the CiscoSecure product based on the following example procedures should be carried out by experienced Oracle database administrators (DBAs) only.
For specific instructions on how to use the above Oracle programs, please refer to Oracle manuals and on-line help.
For each service that you created in Step B, use the Oracle Security Administrator to create a special user with special privileges to control database replication.
Caution This user must not be the Oracle user that you specified as in charge of the DB account for CiscoSecure data during CiscoSecure installation.
execute DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP (userid => 'repadmn')
Create two-way links between the databases. For each database instance, do as follows:
If you are configuring Master-to-Snapshot replication, follow the steps in this section. If you are configuring Master-to-Master replication, skip this section and go to "F. If You are Configuring a Master-to-Master Database Replication Scenario...," page 33.
Step 1 Using the SQL*Plus utility, log in to each database instance that you want to be a Snapshot site.
Step 2 Using the Oracle Replication Manager, create a database connection for each database connection service that you set up in Step B.
Step 3 Using the Oracle Replication Manager, select the database connection that you want to be the Master Definition site and create and configure the master group on this site as follows:
Step 4 Using the Oracle Replication Manager, select and set up each database connection that you want to be a Snapshot site as follows:
Step 5 At the Master Definition database site, change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
CSdbTool cache_trigger
Step 6 At each Snapshot database site, change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
CSdbTool cache_trigger_snap
Step 7 Before you create any new users, configure the Snapshot sites to prevent duplicate user profile names. At each Snapshot site, enter the following command:
CSdbTool ora_rep_indx_snap
Step 8 Edit the initsid.ora configuration file. At each Oracle site, do as follows:
job_queue_interval = minutes
job_queue_processes = number
compatible = 7.1.0.0
compatible = 7.3.0.0
Step 9 At the CiscoSecure ACS for the Master site, restore the listings for the CiscoSecure servers installed at Snapshot sites.
If you are configuring Master-to-Master replication, follow the steps in this section. If you are configuring Master-to-Snapshot replication, ignore this section. See "Precautions Running Oracle Database Replication and CiscoSecure," page 37.
Step 1 Using the SQL*Plus utility, log in to each database instance that you want to be a Master Destination site.
Caution Remember, delete the above tables from Master Destination sites only.
Step 2 For each database connection service, create a surrogate replication administrator.
Caution This user must not be the Oracle user that you specified as in charge of the DB account for CiscoSecure data during CiscoSecure installation.
Step 3 Using the SQL*Plus utility, assign the appropriate privileges to the database surrogate replication administrator at each Oracle site.
execute DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT(userid => 'surrogate_repadmn')
Step 4 Using the Oracle Replication Manager, create a database connection for each database connection service that you set up in Step B.
Step 5 Using the Oracle Replication Manager, select the database connection that you want to be the Master Definition site and create and configure the master group on this site as follows:
Step 6 After creating the master group, set up conflict resolution for each table in the group. Add a column group, give it an arbitrary name, select the PROFILE_TS column to this group, and select the latest time stamp resolution method for this group.
Step 7 Using the Oracle Replication Manager, select and set up the database connection that you want to be a Master Definition site as follows:
Step 8 Using the Oracle Replication Manager, select and set up each database connection that you want to be a Master Destination site as follows:
Step 9 Using the Oracle Replication Manager, carry out the initial replication of the master group in each connection that you set up. For each master group configuration, go to Admin Requests and select the option, Apply all Administrative requests now.
Step 10 At each database site, run the following command line:
CSdbTool cache_trigger
Step 11 In order to prevent two different CiscoSecure servers from assigning the same internal profile ID number to different user profiles, assign non-overlapping ranges of internal profile ID numbers to each Master Destination site as follows:
update cs_id set id = 10000000 -1 where type = 'max_profile'
update cs_id set id = 10000000 where type = 'profile'
update cs_id set id = 10000000 where type = 'min_profile'
update cs_id set id = 20000000 -1 where type = 'max_profile'
update cs_id set id = 20000000 where type = 'profile'
update cs_id set id = 20000000 where type = 'min_profile'
update cs_id set id = 30000000 -1 where type = 'max_profile'
Step 12 After initial replication has occurred, and before you create any new users, configure the Master Destination sites to prevent duplicate user profile names. At each Master Destination site, enter the following command:
CSdbTool ora_rep_indx
Step 13 Edit the initsid.ora configuration file. At each Oracle site, do as follows:
job_queue_interval = minutes
job_queue_processes = number
compatible = 7.1.0.0
compatible = 7.3.0.0
Step 14 Restart the Oracle server to have the changes to the inisid.ora file take effect.
Step 15 At the CiscoSecure ACS for the Master Definition site, restore the listings for the CiscoSecure servers installed at the Master Destination sites.
In cases where Oracle Master-to-Master (or Master-to-Updateable-Snapshot) database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.
If updating of the same user profile at two different sites within the same interval between replications occurs, the user profile edits at neither site will be replicated or reconciled. The user profile will remain with unreconciled settings at both sites, and the following Oracle error message will appear at both sites within the "Local Errors" section of the Oracle Replication Manager tree:
ORA-01403 no data found error
The above error should rarely occur, because, in practice, no more than one administrator, administering from one CiscoSecure ACS site should be authorized to administer any one user profile anyway.
However, if this error does occur, you must fix the unreconciled user profile at both sites as follows:
Step 1 Use the web-based CiscoSecure ACS Administration web pages or the Java-based CiscoSecure Administrator program to do the following:
(a) Examine the user profile settings at each site. Determine which user profile is the one you want replicated and note the settings.
(b) Delete the user profile at both sites.
(c) At one of the sites, create a new user profile with the same name as the profile you just deleted.
(d) Manually configure this user profile with the settings that you wanted.
Step 2 Use the Oracle Replication Manager to force replication, or wait until the next scheduled replication.
The settings for the new user profile will replicate throughout the system.
The following example procedures use the Sybase RS INIT, and rsmgen utilities run on the UNIX server, and Sybping, and Replication System Manager, running on a Windows 95 workstation console, to integrate Sybase database replication with multiple CiscoSecure ACSes.
Caution Implementing Sybase database replication requires an in-depth knowledge of Sybase tools and database structure. Integrating database replication with CiscoSecure based on the following example procedures should be carried out by experienced Sybase database administrators (DBAs) only.
For specific instructions on how to use the above Sybase programs, please refer to Sybase manuals and on-line help.
Sybase supports two types of database replication, Primary-Server-to-Replicate-Server, and Peer-Server-to-Peer-Server.
To carry out database replication, Sybase requires that you install a Replication Server at one of your Sybase database sites and a Replication Server Manager client module at a PC console.
Step 1 At your Primary site, make sure that the Sybase SQL server or Adaptive server module is installed and running.
Step 2 Install the Replication Server and Replication Server Manager modules.
Step 3 Install the Sybase SQL Manager and Replication Manager Client tools on a PC console.
The Sybase Replication Server executes replication among the Sybase database sites. Set it up by using the Sybase RS INIT program following the procedures outlined in your Sybase documentation. RS INIT settings that require specific input in order to integrate Sybase replication of the CiscoSecure database are noted below:
Step 1 Specify the Replication Server Information settings. Except for the settings listed below, accept the default values.
Step 2 Specify the Replication Server Interfaces Information settings. Except for the settings listed below, accept the default values.
Step 3 Accept the default ID Server Information settings.
Step 4 Specify the Replication Server System Database Information settings. Except for the settings listed below, accept the default values.
Step 5 Specify the RSSD Device Information settings. Except for the settings listed below, accept the default values.
Step 6 Specify the Disk Partition Information settings. Except for the settings listed below, accept the default values.
Step 7 Accept all default values for the Remote Site Connections Information settings.
At each CiscoSecure database site run RS INIT to integrate the CiscoSecure database into the Sybase replication system. Set it up by using the Sybase RS INIT program following the procedures outlined in your Sybase documentation. RS INIT settings that require specific input in order to integrate Sybase Replication of the CiscoSecure database are noted below:
Step 1 Specify the Replication Server Information settings. Except for the bulleted settings listed below, accept the default values.
Step 2 Specify the Database Information settings. Except for the bulleted settings listed below, accept the default values.
Step 3 At Primary and Peer database sites only, accept all the default Database Log Transfer Manager settings.
Step 4 At Primary and Peer database sites only, configure the LTM Interfaces Information settings. Except for the bulleted settings listed below, accept the default values.
Step 5 Accept the settings. Note the logfile location on exit.
Set up one Replication Services Manager Server as follows:
Step 1 At the Primary server, use the Sybase DSEDIT utility to create an RSM server entry in the Sybase Interfaces file.
Step 2 In the $SYBASE/Install directory run the rsmgen utility.
Step 3 When prompted for the RSM Server name, specify the name you entered in the Interfaces file.
The rsmgen utility creates a file: RUN_rsmfilename.
where rsmfilename is the name you specified while running rsmgen.
Step 4 Run the RUN_rsmfilename file in background mode. Enter.
./RUN_rsmfilename &
Step 1 Move to the Windows 95 or Windows NT workstation on which you installed the Replication Services Manager client and ping the hosts running all the Sybase servers involved in database replication to test the console-to-Sybase server TCP/IP connections.
Step 2 If the pings are successful, use the Windows-based SQLEDIT program to generate an Interface file on the PC. Point to the IP addresses and TCP/IP ports of the SQL or Adaptive Server, Replication Server, LTM server, and RSM server.
Step 3 Use the Sybping utility to ping the Adaptive Server, Replication Server, LTM server, and RSM server modules and confirm the console-to-server Sybase connections.
Step 4 Start the Windows-based RSM Manager.
Step 5 Select the File>New RSM Domain menu command.
Step 6 To create a RSM domain for your CiscoSecure profile databases, do the following:
Step 7 On each Primary server or Peer server in the RSM Domain, configure replication definitions for each of its tables as follows:
If you are configuring Primary-to-Replication server replication, follow the steps in this section. If you are configuring Peer-to-Peer replication, skip this section and go to "H. If You are Setting Up Peer-to-Peer Replication..," page 42.
Step 1 For each Replicate server in the RSM domain, configure subscriptions to each of the six replication definitions configured in Step F.
Step 2 At each of the CiscoSecure database sites, enable profile caching. Change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
CSdbTool cache_trigger
Step 3 At the CiscoSecure server for the Primary site, restore the listings for the CiscoSecure servers installed at the Replicate sites.
If you are configuring Peer-to-Peer replication, follow the steps in this section. If you are configuring Primary-to-Replicate server replication, ignore this section.
Step 1 Decide which of your Sybase sites will be the initial source Peer site.
When the first replication is run the initial source Peer site will be the site containing the original profile data structures that will be replicated to all the other sites.
All the other sites will be secondary Peer sites.
Step 2 At each secondary peer site, delete the current CiscoSecure profile records.
Start the Sybase ISQL utility and use the delete command to empty the current CiscoSecure profile records. Enter:
delete from cs_profile
delete from cs_user_profile
delete from cs_group_profile
delete from cs_password
delete from cs_privilege
delete from cs_profile_blob
Step 3 At each secondary peer site, configure subscriptions to each of the replication definitions configured in Step F. Use the Replication Services Manager Configure>Subscription option and click the Create tab.
Step 4 At the initial source Peer site, configure subscriptions to each of the replication definitions configured in Step F. Use the Replication Services Manager Configure>Subscription option and click the Define tab.
Step 5 At each CiscoSecure database site enable profile cache updating. Change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
CSdbTool cache_trigger
Step 6 In order to prevent two different CiscoSecure servers from assigning the same internal profile ID number to different user profiles, assign non-overlapping ranges of internal profile ID numbers to each Peer site as follows:
update cs_id set id = 10000000 -1 where type = 'max_profile'
update cs_id set id = 10000000 where type = 'profile'
update cs_id set id = 10000000 where type = 'min_profile'
update cs_id set id = 20000000 -1 where type = 'max_profile'
update cs_id set id = 20000000 where type = 'profile'
update cs_id set id = 20000000 where type = 'min_profile'
update cs_id set id = 30000000 -1 where type = 'max_profile'
Step 7 Restart the CicsoSecure ACS at each site if it is running.
Step 8 At the CiscoSecure ACS for either the initial or a secondary Peer site, restore the listings for the CiscoSecure servers installed at the secondary Peer sites.
In cases where Sybase Peer-to-Peer database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.
If updating of the same user profile at two different sites within the same interval between replications occurs, the user profile edits at neither site will be replicated or reconciled. The user profile will remain with unreconciled settings at both sites.
In practice, this error is unlikely to occur for two reasons:
However, if the above error does occur, fix the unreconciled user profile as follows:
Step 1 Use the web-based CiscoSecure ACS Administration web pages or the Java-based CiscoSecure Administrator program to do the following:
(a) Examine the user profile settings at each site. Determine which user profile is the one you want replicated and note the settings down.
(b) Delete the user profile at both sites.
(c) At one of the sites, create a new user profile with the same name as the profile you just deleted.
(d) Manually configure this user profile with the settings that you wanted.
Step 2 Wait until the next scheduled replication.
The settings for the new user profile will replicate throughout the system.
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
.
|
|