Cisco Secure Access Control Server for Unix

Table of Contents

Release Notes for CiscoSecure ACS 2.2.2 for UNIX

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:

Note "Appendix G Update" in these release notes updates and completely replaces "Appendix G" in the printed version of the CiscoSecure ACS 2.2.2 for UNIX User Guide.

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.

New Information About CiscoSecure ACS 2.2.2

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.

Configuring the CiscoSecure ACS AutoRestart Feature

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:

Disables AutoRestart. If used, CiscoSecure will not restart if the AAA server or DBServer aborts. The AutoRestart feature is on by default.

Example: S80CiscoSecure noauto

Disables the autosave of core files during restart. If used, the CiscoSecure ACS will not save the core files into the $BASEDIR/corefiles directory during restart. Any core files contained in the DBServer and CSU directories will remain in their respective directories.

Example: S80CiscoSecure nosavecore

Instructs CiscoAuto not to save the core files in event of an abort and restart.

Example: S80CiscoSecure nosavecore 5

Instructs CiscoAuto to check the AAA server component every 5 seconds and, in the event of a shutdown and restart, not to save the core files.

Sets the sample monitoring time. Sample time is the number of seconds between checking if the AAA server has aborted. When not supplied, the default is 30 seconds. To set the sampling time, provide a numeric value with the command-line switch.

Example: S80CiscoSecure 5

Checks that the AAA server is running every 5 seconds.

Example: S80CiscoSecure 60

Checks once a minute that the AAA server is running.

Importing a TACACS+ Freeware Database to CiscoSecure

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

Example Import

To create an import file from a TACACS+ freeware configuration file named "myoldconfigfile," the system administrator would follow these steps.

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.

Additional NAS Command for Token Card Support

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:

The default setting of one second will cause OTP logins to fail a large percentage of the time.

Restricting Client Access to the CiscoSecure ACS Administration Tools

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 2   Insert or edit the following lines to the [ValidClients] section of the CSConfig.ini file:

where:

Note Repeat the line ID_num = my_wrk_station to assign a unique ID number to every workstation that you want to access the CiscoSecure ACS administration web pages or the CLI with.

ValidateClients = true restricts access to only those workstations assigned IDs in the [ValidClients] section.

ValidateClients = false allows any workstation to access the CiscoSecure ACS administration web pages or CLI whether or not it is specifically listed in the [ValidClients] section.

Step 3   After editing the CSConfig.ini file, restart the CiscoSecure ACS to apply the changes.

Example CSConfig.ini [ValidClients] Settings

In the following example:

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:

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.

Supporting ISDN Multilink Users on Cisco IOS Release 11.3 or Higher

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.

Assigning Password Privilege Levels through the Command Line Interface

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.

New CSU.cfg Variables

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.

Disabling Features to Improve Authentication Performance

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," to decide whether you need the feature they enable or not. For additional information on config_maxsessions_enable, see also "Limiting Sessions Per User,".

Limiting Sessions Per User

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.

Assigning the "server max-sessions" Attribute

Assign the max-sessions attribute as follows:

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:

Note Each B channel in an ISDN connection is considered a session.

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.

Configuring High-Performance Max-Sessions Checking

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:

where:

Note This setting does not actually close or time out a CiscoSecure session; rather, it is used to "clean up" the records of sessions that should have already closed or timed out but that, for some reason, have not been noted as closed by the max-sessions counter and thus not decremented. To set actual time out values for your users' CiscoSecure sessions, apply the TACACS+ timeout attribute or the RADIUS session-timeout attribute to their group or user profiles.

The value you specify for session_minutes should equal or exceed, in minutes, the actual timeout time that you set by applying the TACACS+ timeout attribute or RADIUS session timeout attribute to the group or user profile.

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.

Configuring Highly Persistent Max-Sessions Checking

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 2   In the CSConfig.ini file, make sure the following parameters are set in the [AccountingMgr] section:

where:

For example, the setting:

AcctPurgeInterval = 75

does not necessarily guarantee that a purge check will be performed every 75 minutes. It does guarantee that a purge check will be performed no more frequently than once every 75 minutes. The actual interval between purge checks could be anything from 75 minutes to 135 minutes.

The minimum value for this variable is 60 minutes.

Note This setting does not actually close or time out a CiscoSecure session, rather it is used to "clean up" the records of sessions that should have already closed or timed out but that, for some reason, have not been noted as closed by the max-sessions counter and thus not decremented. To set actual timeout values for CiscoSecure sessions, apply the TACACS+ timeout attribute or the RADIUS session-timeout attribute to a group or user profile.

The value you specify for session_minutes should equal or exceed, in minutes, the actual timeout period that you set through your profile attributes. The minimum value is 60 minutes.

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.

Temporarily Disabling Max-Sessions Checking

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 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.

Reading AAA Server Metrics Information in the csuslog File

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:

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:

Because requests can be processed in parallel, the value displayed in the TotalSec column may be higher than the actual chronological passage of time. For example, if 20 simultaneous requests are made to the Profiles database and the system simultaneously processes each request using one processor second per request, then the value in the TotalSec column would increment by 20 processor seconds even though only one second of chronological time may have passed.

Note The values in the TotalReqs and TotalSec columns are based on the database requests made and the processor seconds consumed since the last time the CSU.cfg variable enable_config_metrics was disabled and re-enabled and the CiscoSecure ACS was re-initialized. (See "New CSU.cfg Variables," 6 for a description of the enable_config_metrics variable.)

Troubleshooting "Severe SQL Error" Messages

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:

where date is the date the log file is created. For example, csdblog_98-MAR-28.

Accessing Information in the csdblog_date Log Files

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.

Typical Contents of a csdblog_date Log File

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):

A Common DBServer Module Error Message in the csdblog_date Log File

An example of a common DBServer-generated message that might appear in a csdblog_date log file, is:

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.

Changing the csdblog_date File Logging Level

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:

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.

Accessing Information in the DBServer.log

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.

Changing the Default TCP/IP Port Number of the Netscape FastTrack Server

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.

to

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

where: new_port_num is the new TCP/IP port value.

Enabling SSL on the Web Server

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:

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.

Using New Support for Caller ID

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:

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,".

User's Profile

The profile attribute Privilege - Web will accept a blank password (input as a blank space in the password field) as valid.

Improving General GUI Performance with Netscape Navigator

Use the following procedures to increase GUI performance on Netscape Navigator browser.

Increase Memory and Disk Cache

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.

Clear Cache Memory after CiscoSecure ACS Upgrade

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.

Additional Methods of Authenticating One-Time Password Cards via PPP

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:

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:

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.

Even though you've assigned a dummy string in your users' Password-PAP attribute, they do not enter it during log in. In fact, they do not even need to know what the dummy string is.

Netscape Virtual Memory Management

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.

Considerations for a Total Security Solution

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.

Physical Security of the CiscoSecure ACS

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.

Physical Security of Access Server Clients

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).

Securing Firewall Configurations

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.

Securing the Local Network Access

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.

Choosing a Password

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.

Transmitting Passwords

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.

Installing CiscoSecure ACS

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.

Passing Configuration Information

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."

Protecting Your Web Server

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.

Existing Issues with CiscoSecure ACS 2.2.2

This section identifies issues with CiscoSecure ACS 2.2.2 and related information. Some of these issues will be addressed in a subsequent release.

Scaling Limitations of the SQLAnywhere Database Option

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.

Internet Explorer 4.0 Issues

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.

Internet Explorer 3.02 Issues

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.

After you click OK in a dialog box in Internet Explorer 3.02, the focus will temporarily shift somewhere else, then shift back to Internet Explorer.

In the Members tab of the Java-based CiscoSecure Administrator advanced configuration program, when you click the gray area of the scroll bar for the tree (the area that contains neither the arrows nor the scroll button), portions of the tree momentarily flash on the screen. Additionally, the scrolling goes very slowly.

In the Dictionaries tab of the Java-based CiscoSecure Administrator advanced configuration program, clicking on the gray area of the scroll bar should take the user up or down one full screen. IE scrolls more than a single screen with each click. To view all the data your must click the arrows on the scroll bar or drag the slider.

Navigator 4 for Solaris and the Security Socket Layer Feature

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]

CiscoSecure ACS Web Pages Cannot Directly Delete SafeWord Users

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]

SDI-Based Authentications can Experience Server Malfunctions

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]

Ascend-RADIUS Dictionary Needs Updating and Correction

The Ascend-RADIUS dictionary supplied with CiscoSecure ACS 2.2 for UNIX requires the following updating and correction:

529,1 = Ascend-avpair string

where 529 is the Ascend vendor ID. [CSCdj45006]

This will affect only those users who are attempting to use subattributes of the vendor-specific attribute. Currently, Ascend does not employ the vendor-specific attribute, so it is expected that this will not affect any users; however, if you need to use an Ascend vendor-specific attribute, you can overcome this limitation by manually editing the dictionary using the CLI tools.

Cisco-RADIUS Dictionary Needs Updating

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]

The Java-Based CiscoSecure Administrator Might Display a Misleading Error Message

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:

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 Might Not Support Large User Group Profiles

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:

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]

Working with Slow GUI Performance

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.

Changing the Username and Password on the Web Server

To change the username and password on your FastTrack Server, perform the following steps:

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.

Note The default username is admin and the default password is password.

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.

Problems Updating the same CiscoSecure User Profile at Different CiscoSecure ACS Sites

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," or "Precautions Running Sybase Database Replication and CiscoSecure,". [CSCdj79568]

Problems With Failed User Logins at Two or More Sites

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:

Problems With Oracle 7.3.3 and Earlier Client Modules

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]

Problems With Failed Accounting Record Updates

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:

Problems with Oracle Core Data Dumps

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 2   Delete the existing process.dat and regid.dat files and recreate them to the default size.

Step 3   Edit the Oracle user's shell startup file. For Bourne or Korn shell users the settings to add or edit are:

Step 4   Stop and restart the Oracle server. [CSCdj85981]

Corrections to the User Guide

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 last paragraph in this section no longer applies to TACACS+ accounting.

You cannot configure the RDBMS through the CiscoSecure web-based interface; You can, however, configure the CiscoSecure ACS through the web-based interface to record accounting packets to the RDBMS.

To quickly disable this feature on a global basis without laboriously removing the "Accounting function" attribute from each user profile, disable the config_acct_fn_enable variable in the CSU.cfg file. See "New CSU.cfg Variables," for more information.

Steps 7 and 8 are no longer necessary for this procedure.

The file skey-cs.tar referred to in the note is available at the Cisco web page:

http://www.cisco.com/pcgi-bin/tablebuild.pl/ciscosecure

An additional AddProfile command-line switch, -prv, enables you to specify required privilege level along with password requirements when creating profiles through the CLI. See "Assigning Password Privilege Levels through the Command Line Interface,", of these release notes for details.

In Tables F-1 through F6, the following additional information applies to the profile_ts column description: Oracle database replication supports restricted time stamp-based conflict resolution for the CiscoSecure ACS. Sybase database replication does not provide native time stamp-based conflict resolution. See the appendix, "Integrating Oracle or Sybase Database Replication and CiscoSecure" for details.

GLOBAL NOTICE: The information in this Appendix G is obsolete. For the most recent updates on CiscoSecure database replication, see the appendix update, "Appendix G Update: Setting Up Database Replication among CiscoSecure ACSes," of these release notes.

Updated Copyright Information

The following information supplements the copyright information in the user guide:

Appendix G Update: Setting Up Database Replication among CiscoSecure ACSes

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.

Examples

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 1   Master-to-Snapshot Replication

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.

Figure 2   Peer-to-Peer Replication

Integrating Oracle Database Replication with CiscoSecure

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.

For specific instructions on how to use the above Oracle programs, please refer to Oracle manuals and on-line help.

A. Plan your Oracle Database Server Distribution System

If you are planning to implement Master-to-Snapshot Replication, decide which of your Oracle database servers will become the Master database site. The remainder of your Oracle servers will become Snapshot sites.

If you are planning to implement Master-to-Master Replication, decide which of your Oracle Database servers will become the Master Definition site. The remainder of your servers will become Master Destination sites.

B. Create Connection Services from the Console to all Database Sites

If you do not have connectivity, locate the tnsnames.ora file in the $ORACLE_HOME/network/admin directory and edit it, making sure that entries exist for all the other Oracle database sites involved in the replication.

C. Create a Special User as the Replication Database Controller

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.

Note If you are configuring a Master-to-Updateable-Snapshot replication system, assign the database the EXECUTE privilege on the SYS.DBMS_DEFER PL/SQL object to the database replication control user. For more information on updateable snapshot replication, see the bulleted item "Enable or disable the update option for each snapshot in the group,".

execute DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP (userid => 'repadmn')

where repadmn is the name of the database replication control user that you just created.

D. Create Links Between Databases

Create two-way links between the databases. For each database instance, do as follows:

E. If You are Configuring a Master-to-Snapshot Replication Scenario...

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...,".

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:

Disabling the update option—Causes the Snapshot site to be read-only. Configuring read-only Snapshot sites ensures that CiscoSecure administration can only be carried out at the Master site.

Note However, a read-only Snapshot site also denies CiscoSecure users, even those with user-level web privilege, the ability to change their personal passwords via the user-level CiscoSecure ACS administration web page, and disables the maximum failed login limitations at those CiscoSecure ACS sites.

Enabling the update option—Causes the Snapshot site to be updateable. Configuring updateable Snapshot sites allows CiscoSecure users with user-level web privilege to change their personal passwords and preserves the maximum failed login limitations.

Note However, the presence of updateable Snapshot sites means that exclusive CiscoSecure administration from the Master site is not ensured. Conflicting administrative information entered at different sites might require special steps to resolve. See "Precautions Running Oracle Database Replication and CiscoSecure,".

From the refresh group properties menu, schedule the interval (for example, every 24 hours) when the update should occur.

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

Note The CSdbTool cache_trigger command line enables replication changes to the profile database of a CiscoSecure ACS to be incorporated in the profile cache of that ACS also. When the replication process updates a record in the profile database, the cache triggers write the updated records to the cs_trans_log table, which is read by the CiscoSecure DBServer module, which, in turn, incorporates the changed records in the ACS profile cache.

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:

Step 8   Edit the initsid.ora configuration file. At each Oracle site, do as follows:

where sid is the system identification name of the Oracle server.

job_queue_interval = minutes

job_queue_processes = number

where:

minutes is the number of minutes between updates. This value must be equivalent to the update interval time that you set in the refresh group properties menu in the Oracle Replication Manager. (See Step 4, "Using the Oracle Replication Manager, select and set up each database connection that you want to be a Snapshot site as follows:,")

number is the number of background processes allotted to the replication operations (must be at least one).

compatible = 7.1.0.0

to:

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.

Notice the that the IP listings for the CiscoSecure servers installed at Snapshot sites are not listed.

F. If You are Configuring a Master-to-Master Database Replication Scenario...

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,".

Step 2   For each database connection service, create a surrogate replication administrator.

(a.) Create a special user, a surrogate replication administrator, to control database replication.

(b.) For the user's Default table space, specify the Oracle tablespace that you set up for CiscoSecure before 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')

where surrogate_repadmn is the name of the surrogate replication administrator that you just created.

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:

Note Profile ID numbers are unique numbers internally assigned to user profiles by CiscoSecure for internal tracking. The absolute range of permissible profile ID numbers is between 1 and 2,147,483,647.

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'

Note At each site, when setting minimum and maximum profile ID range, be sure to set a range sufficient to accommodate anticipated growth in the required profile ID numbers.

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:

Step 13   Edit the initsid.ora configuration file. At each Oracle site, do as follows:

where sid is the system identification name of the Oracle server.

job_queue_interval = minutes

job_queue_processes = number

where:

minutes is the number of minutes between updates. This value must be equivalent to the intervals required when you created the scheduled links in Step 7 and Step 8 of Step F.

number is the number of background processes allotted to the replication operations (must be at least one).

compatible = 7.1.0.0

to:

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.

Notice the that the IP listings for the CiscoSecure servers installed at Master Destination sites are not listed.

Precautions Running Oracle Database Replication and CiscoSecure

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:

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 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.

Integrating Sybase Database Replication with CiscoSecure

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.

For specific instructions on how to use the above Sybase programs, please refer to Sybase manuals and on-line help.

A. Plan Your Sybase Replication System

Sybase supports two types of database replication, Primary-Server-to-Replicate-Server, and Peer-Server-to-Peer-Server.

If you are planning Primary-Server-to-Replicate-Server replication, decide which of your Sybase servers will become the Primary Server site. The remainder will become Replicate Server sites.

If you are planning Peer-to-Peer replication, you should still select a Primary server on which to install the replication server software.

B. Install the Replication Server Modules

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 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.

C. Configure the Sybase Replication Server

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 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.

Note In this context, the RSSD device is an area on a hard disk or some other storage device that you are reserving to store Replication System configuration data.

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.

If this file does not already exist, use the UNIX touch utility to create it. When creating this file, you must be logged in as the Sybase user, rather than as root.

The filename that you specify must not contain a period.

Note The disk partition settings specify a partition area on which the actual profile database information to be replicated is stored.

Step 7   Accept all default values for the Remote Site Connections Information settings.

D. Add the CiscoSecure Databases to the Replication

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 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.

E. Set Up the Replication Services Manager Server

Set up one Replication Services Manager Server as follows:

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 &

F. Start the PC Replication Services Management Program

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:

G. If You are Setting Up Primary-to-Replicate Server Replication..

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..,".

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:

Note The CSdbTool cache_trigger command line enables replication changes to the profile database of a CiscoSecure ACS to be incorporated in the profile cache of that ACS. When the replication process updates a record in the profile database, the cache triggers write the updated records to the cs_trans_log table, which is read by the CiscoSecure dbserver module, which, in turn, incorporates the changed records in the ACS profile cache.

Step 3   At the CiscoSecure server for the Primary site, restore the listings for the CiscoSecure servers installed at the Replicate sites.

Notice the that the IP listings for the CiscoSecure servers installed at Replicate sites are no longer listed.

H. If You are Setting Up Peer-to-Peer Replication..

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.

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:

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:

Note The CSdbTool cache_trigger command line enables replication changes to the profile database of a CiscoSecure ACS to be incorporated in the profile cache of that ACS. When the replication process updates a record in the profile database, the cache triggers write the updated records to the cs_trans_log table, which is read by the CiscoSecure DBServer module, which, in turn, incorporates the changed records in the ACS profile cache.

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:

Note Profile ID numbers are numbers internally assigned to user profiles by CiscoSecure for internal tracking. The absolute range of permissible profile ID numbers is between 1 and 2147483647.

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'

Note At each site, when setting minimum and maximum profile ID range, be sure to set a range sufficient to accommodate anticipated growth in the required profile ID numbers.

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.

Notice the that the IP listings for the CiscoSecure servers installed at secondary Peer sites are no longer listed.

Precautions Running Sybase Database Replication and CiscoSecure

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 2   Wait until the next scheduled replication.

The settings for the new user profile will replicate throughout the system.

Cisco Connection Online

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.

.