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.