|
|
September 23, 1998
This document provides new information about CiscoSecure Access Control Server (ACS) 2.2(3) for UNIX that became available after the CiscoSecure ACS 2.2.2 for UNIX User Guide was prepared. This document includes:
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more up to date than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
This section provides the latest information about this version of the CiscoSecure ACS 2.2x for UNIX software. Information is updated immediately prior to release of the software. The following topics are included:
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:
The CiscoSecure ACS startup process has been enhanced to autorestart the CiscoSecure ACS if its AAA or DBServer components abnormally abort. To provide this functionality, a new process, "CiscoAuto," is started during CiscoSecure startup. If the AAA or DBServer component aborts, CiscoAuto detects this event and performs a CiscoSecure restart. During this process, the following events occur:
1. The CiscoSecure ACS is shut down.
2. Any core files in the CSU or DBServer directories are moved to $BASEDIR/corefiles and compressed.
3. The CiscoSecure ACS is restarted.
The AutoRestart feature can be customized or disabled by specifying several command-line switches with the S80CiscoSecure startup command. The switches are as follows:
The conversion utility, cnv, allows you to import a public domain TACACS+ freeware database into a CiscoSecure ACS 2.x for UNIX database. With cnv, you can create an intermediate file (import file) that can then be imported into the 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_Configwhere
To create an import file from a TACACS+ freeware configuration file named "myoldconfigfile," the system administrator would follow these steps:
Step 1 Type: cnv <myoldconfigfile> mynewimportfile
Step 2 Break the mynewimportfile file into the AAA.cnf and newuser.dat files.
Step 3 Run CSimport to import the user profiles:
CSimport -c -p /dir -s newuser.dat
CiscoSecure ACS support for token card-generated, one-time password (OTP) logins requires the host network access server (NAS) to be configured with a minimum 10-second TACACS+ timeout setting:
tacacs-server timeout 10
The default setting of one second will cause OTP logins to fail a large percentage of the time.
You can edit the CSConfig.ini file to restrict administrative access to the CiscoSecure ACS administration web pages and command-line interface (CLI) to a specified list of workstations to which you have assigned IDs.
Step 1 Locate the CSConfig.ini file in the $BASEDIR/config directory of the CiscoSecure ACS 2.2(3) installation.
Step 2 Insert or edit the following lines to the [ValidClients] section of the CSConfig.ini file:
where:
Step 3 After editing the CSConfig.ini file, restart the CiscoSecure ACS to apply the changes.
In the following example, two workstations, with the FQDNs of ws-barrylee and ws-pameagan, are authorized to access the CiscoSecure administration tools:
[ValidClients] 100 = ws-barrylee 120 = ws-pameagan ValidateClients = true
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:
[ValidClients] 100 = ws-barrylee 120 = ws-pameagan ValidateClients = false
If your TACACS+ NASes are running Cisco IOS Release 11.3 or higher, and you want to support CiscoSecure authorization of users who are dialing in over multiple ISDN channels, use the Java-based CiscoSecure Administrator advanced configuration program to add the protocol = multilink attribute-value to the profiles of the affected users.
CiscoSecure ACS 2.2(3) provides a new command switch, -prv, for the CLI AddProfile command.
In contrast to the existing -pw switch, which enables you to specify password type and password, the new -prv switch enables you to specify password type, password, and privilege-level requirements, if necessary, to new user profiles. The new syntax for the AddProfile command is:
AddProfile[-h host] -p port [-id client] {-u user | -g group} [-pr parent-group] [-pw password-pair] [-prv password-trio] [-a profile-info][-q]In the AddProfile command syntax, the -pw and -prv switches are mutually exclusive. Use the -pw switch when creating profiles with passwords but no privilege-level requirements; use the -prv switch when creating profiles with password and privilege-level requirements.
The following table describes and contrasts the -pw and -prv switches.
| Switch | Command Type | Description |
|---|---|---|
-pw | password pair (optional) type, password or type | Defines which passwords to add to the user's profile.
-pw ARAP,2sAmzpwRd
-pw SDI |
-prv | password trio (optional) type, password, privilege level or type, privilege level | Defines which password and privilege level requirement (if necessary) to add to the user's profile.
-prv clear,2sAmzpwRd,13
-prv SDI,13 |
CiscoSecure ACS 2.2(3) provides a CLI command UpdatePassword, which enables the system administrator to assign a new password to a user or group account in case the user or group members have forgotten the old password or are unavailable to provide that information.
The UpdatePassword command works the same as the ChangePassword command except that it does not require the old password to be specified.
To change a user's forgotten password enter:
UpdatePassword [-h host] -p port [-id client] -u userTo change a group's forgotten password enter:
UpdatePassword [-h host] -p port [-id client] -g groupThe following table describes the UpdatePassword switches.
| Switch | Command Type | Description |
|---|---|---|
-h | host (optional) | Name of the host where the CiscoSecure native database is located---almost always the same host where the CiscoSecure ACS is installed. Required if using command remotely. |
-p | port | CiscoSecure ACS database server port with which to communicate. |
-id | client (optional) | Client ID. |
-u | user | User's name whose passwords are being changed. |
-g | group | Group's name whose passwords are being changed. |
-pr | password's protocol type | Type of protocol being changed, such as CHAP, ARAP, PAP, and so on. |
-npw | new password | New password. |
-q | suppress output (Optional) | Suppresses user output. |
| Message | RC1 | Description |
|---|---|---|
No Error | 0 | Indicates no error. The password has been successfully changed. |
Input Error | 1 | Error in the data provided by the users. |
Connection Error | 66 | Cannot connect to the ACS database server. |
Socket Error | 64 | Error occurred establishing a socket. |
Stream Error | 65 | Error occurred establishing a data stream between the ChangePassword and CiscoSecure. |
Password Error | 3 | Invalid password type or password was provided in the -npw, or -pr switches. |
Password Not Changed | 5 | Password did not change. |
| 1RC = return code |
In the following example, the password of the user user_joe is changed to mynewpassword:
UpdatePassword -h mymachine -p 9900 -id 100 -u user_joe -pr ARAP -npw mynewpassword
In the second example, the password of the group group1 is changed to ournewpassword:
UpdatePassword -h mymachine -p 9900 -id 100 -g group1 -pr ARAP -npw ournewpassword
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. Some variables that are not new but are not described in the current user guide are also listed in the following table.
String /var/log /CSAccountingLog The file where accounting records are stored, during the accounting packet buffering process, in case of database failure. Example: Number 0 (disable) Whether to enable or disable AAA server metrics monitoring. This feature records AAA server performance statistics (such as transactions per second, total authentications) in the csuslog file. 1 = enable; 0 = disable Example: For a description of the AAA server metrics, see "Reading AAA Server Metrics Information in the csuslog File,". See the config_metrics_log_interval description for other related information. Important: AAA server metrics information can cause the csuslog file to grow extremely large. We recommend enabling this feature only for short periods of time. Number 8 (seconds) Number of seconds between the AAA metrics updates to the csuslog file. See the config_metrics_enable description in this table for related information. Example: Number 1 (enable) Whether to enable or disable the use of the caller ID as a username when a username cannot be found. If the caller ID support feature is not required, we recommend disabling it to improve authentication performance. 1 = enable; 0 = disable Example: For details on caller ID support, see "Using New Support for Caller ID,". Number 1 (enable) Whether to enable or disable use of the default unknown_user profile if the user/caller ID can't be found. If the unkown_user/caller ID support feature is not required, we recommend disabling it to improve authentication performance. 1 = enable; 0 = disable Example: Number 0 (disable) Whether to enable or disable the AAA server implementation of a group or user profile's "server max-sessions" attribute. 1 = enable; 0 = disable Example: Important: See the section "Limiting Sessions Per User,", before setting this variable. Number 1440 (minutes) Number of minutes after which a session will be considered closed by the CiscoSecure max sessions counter. The purpose of this variable is to remove from the max sessions count sessions that should be timed out, but that, for some reason, have not been noted as closed or decremented by the max sessions counter. It does not actually enforce closure of the session in the NAS. Example: Important: See the section "Limiting Sessions Per User,", before setting this variable. Number 60 (minutes) Interval in minutes between checking the possible timeout of sessions for the purpose of updating the max sessions counter. Example: Important: See the section "Limiting Sessions Per User,", before setting this variable. Number 1 (enable) Whether to enable or disable inclusion of per user group membership information in an accounting record if a user profile has the "accounting feature" attribute added. When this function is disabled, an accounting record for a user session will not insert group information in the accounting record. 1 = enable; 0 = disable Example: For details on the accounting feature attribute and group membership accounting information, see the chapter "CiscoSecure ACS Accounting" in the CiscoSecure ACS 2.2.2 for UNIX User Guide. Number config_cache_group_timeout 5 (seconds) Number of seconds to maintain group profile records in the ACS profile cache. Normally group profiles are maintained in the profile cache for only short periods to save system memory; however, if group profile information is frequently accessed for ACS authentication, authorization, and accountng functions, you can improve performance by extending the seconds a group profile remains in cache before timing out. 0 = no timeout Example: Number config_hex_string_support_ enable 0 (disable) Whether to enable or disable use of hex string in the RADIUS string type. This variable can be toggled to enable ACS output of raw binary data required by certain models of U.S. Robotics NASes. If this function is enabled, you can enter any binary string by using "0x" followed by the hexadecimal representation of the string you wish to output. For example, "0x30313a3222" would generate "01:23." 1 = enable; 0 = disable Example: NA config_update_log_filename NA This variable is no longer used. NA config_record_write_ NA This variable is no longer used. Number config_local_timezone 0 (UMT) The local time zone in relation to Universal Mean Time (Greenwich Mean Time). For example, zero is Universal Mean Time; -5 is United States Eastern Standard Time; -8 is United States Pacific Standard Time. This setting is normally determined by the value you specify for the Local Timezone field in the CiscoSecure ACS AAA>General web page. Number config_max_failed_ 10 The maximum number of failed authentications allowed until a profile is disabled. This feature minimizes the possibility of successful "random password generator" attacks on CiscoSecure user accounts. This setting is normally determined by the value you specify for the Max. Failed Authentications field in the CiscoSecure ACS AAA>General web page. Number config_token_cache_absolute_timeout 86400 (seconds in one day) The absolute number of seconds that a token password will be cached for users being authenticated through the CiscoSecure ACS. This is the timeout for the tokens that are using method=session. There are cases where a token can remain valid forever if the stop record was lost. This is meant to be a safeguard parameter that does not allow any token (method=session) to remain valid beyond the configured time. This setting is normally determined by the value you specify for the Token Cache Absolute Timeout field in the CiscoSecure ACS AAA>General web page. Number config_use_keepalives 1 (enabled) This is a parameter used to set the TCP sockets. Do not change this value. List config_external_parser_ NA The name of the parser library used to parse CiscoSecure profiles. Do not change this value. String config_server_ip_address NA The IP address of the CiscoSecure ACS. Do not change this value.
Table 1: Additional Variables in the CSU.cfg File
Type
Name
Default
Description and Example
STRING config_acct_filename = "/spec/Acct";
NUMBER config_metrics_enable = 1;
NUMBER config_metrics_log_interval = 10;
NUMBER config_callerid_enable = 0;
NUMBER config_defaultuser_enable = 0;
NUMBER config_maxsessions_enable = 1;
NUMBER config_maxsessions_session_timeout = 60;
NUMBER config_maxsessions_purge_interval = 90;
NUMBER config_acct_fn_enable = 0;
NUMBER config_cache_group_timeout = 240
NUMBER config_hex_string_support_enable = 1
frequency
authentication
symbols
To improve authentication performance, you can set some of the CSU.cfg variables described in the section "Additional 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 "Additional 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,".
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. Then you can tune the feature for performance or reliability or disable it by editing the CSU.cfg and CSConfig.ini files.
Assign the max-sessions attribute as follows:
Step 1 Start the Java-based CiscoSecure Administrator advanced configuration program.
Step 2 In the Members tab, deselect browse, select the group or user profile that you want to apply the max-sessions 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:
Step 6 Click Apply, then click Submit.
Step 7 In the server's $BASEDIR/config directory, edit the CSU.cfg and CSConfig.ini files to enable and tune the max-sessions feature to meet your particular requirements.
If you want the highest-performance max-sessions checking, configure max-sessions to be executed by the CiscoSecure AAA server module. Edit the CSU.cfg and CSConfig.ini files as follows:
Step 1 In the CSU.cfg file, make sure the following variables are set:
where:
Step 2 In the CSConfig.ini file, make sure the following parameters are set in the [AccountingMgr] section:
Step 3 In order to implement the CSConfig.ini and CSU.cfg edits, restart the CiscoSecure ACS.
Under this configuration, the session count for your users whose profile is assigned a server max-sessions attribute will be maintained and enforced; however, if CiscoSecure is disrupted and restarted for any reason, the session count for those users will be reset to 0.
If you want highly reliable 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 the event of a CiscoSecure shutdown. Edit the CSU.cfg and CSConfig.ini files as follows.
Step 1 In the CSU.cfg file, make sure the following variables are set:
Step 2 In the CSConfig.ini file, make sure the following parameters are set in the [AccountingMgr] section:
where:
AcctPurgeInterval = 75 Step 3 In order to implement the CSConfig.ini and CSU.cfg edits, restart the CiscoSecure ACS.
Under this configuration, the session count for your users whose profile is assigned a server max-sessions attribute will be maintained and enforced; if CiscoSecure is disrupted and restarted, the session count for those users will be preserved and restored.
To disable max-sessions checking without deleting the server max-sessions attribute from each profile, edit the CSU.cfg and CSConfig.ini files as follows:
Step 1 In the CSU.cfg file, make sure that the following variable is set:
Step 2 In the CSConfig.ini file make sure the following parameters are set in the [AccountingMgr] section:
Step 3 To implement the CSConfig.ini and CSU.cfg edits, restart the CiscoSecure ACS.
The ms_util tool provides a menu and prompt-driven method for the system administrator to manage a High-Performance, AAA server-based implementation of max-sessions checking. Using ms_util, the administrator can browse max sessions information for current active sessions and delete active sessions records from the AAA server-based max-sessions counter.
Before executing the delete operations, the system administrator can store the delete commands in an editable file of queued delete commands.
To view the max-sessions counter records of active sessions, follow these steps:
Step 1 Start the ms_util utility.
Go to the $BASEDIR/MaxSessions_utils directory and enter:
Step 2 In the Main menu, select 1 to view the current active sessions.
Step 3 In the View menu, enter the number for one of the following options:
.
| Number and Option | Description |
|---|---|
1 browse-users | Displays a numbered, alphanumerically ordered list of all active user sessions, by username (10 entries displayed per screen, numbered 0 - 9). In addition to username each record also includes: NAS, session number, session length, and start time.
|
2 view-user | Displays all the active sessions of a specific user. Enter the name of the user whose sessions you want to view. |
3 browse-nas | Displays a numbered, alphanumerically ordered list of all NASes with active user sessions (maximum 10 entries per screen, numbered 0 - 9).
|
4 view-nas | Displays all the active sessions of a specific NAS.
|
5 refresh | Updates the current screen of information. |
Step 4 The max-sessions counter active sessions records are displayed in a format similar to the following example:
--------------------------------------------------------------------
-Users with active sessions as of Wed Feb 11 10:20:00 1998-
User Nas Session Active Start
0) user100 nas1.com 110 00:11 Wed Feb 11 10:09:00 1998
1) user102 nas1.com 1011 01:15 Wed Feb 11 09:05:12 1998
--------------------------------------------------------------------
The preceding example indicates that user100 logged on to nas1.com at 10:09 a.m. and the session has been active for 11 minutes; user102 logged in at 9:05 a.m. and this session has been active for 1 hour and 15 minutes.
To delete the records of active sessions from the AAA server-based max-sessions counter, follow these steps:
Step 1 Start the ms_util utility.
Go to the $BASEDIR/MaxSessions_utils directory and enter:
Step 2 In the Main menu, enter 2 to delete active sessions.
Step 3 In the Delete menu, enter the number for one of the following options:
| Number & Option | Description |
|---|---|
1 delete-user | Clears all records in the max-sessions counter of current sessions associated with a specific user.
or
|
2 clear-nas | Clears all records in the max-sessions counter of current sessions associated with a specific NAS.
or
|
3 clear-all | Clears all records of active sessions from the max-sessions counter. The max-sessions count of all users is set to zero. |
4 refresh | Updates the current screen of information. |
Step 4 After entering the options in Step 3, press Enter to place your Delete operation in the job request queue. You return to the main menu.
Step 5 If you have other delete operations to carry out, repeat steps 2, 3, and 4.
Step 6 After specifying all the Delete operations you want carried out, enter 6 in the Main menu to execute the Delete commands in your job queue.
You can add switches to the ./ms_util command-line string and carry out the delete operations described in "Deleting Active Sessions Records" in command-line mode.
If you want to carry out ms_util deletions in command-line mode, the syntax is:
./ms_util [-u user_id, nas _id, session_id] [-n nas_id] [-e]
The command-line switch options and parameters are explained as follows:
| Switch | Description |
|---|---|
| -u | Deletes one specified record of an active session in the max-sessions counter associated with a specific user. The -u switch is specified with the following parameters: ./ms_util -u user_id, nas_id, session_idwhere:
Example:
./ms_util -u john,ciscoNAS,103 |
| -n | Deletes all records of active sessions in the max-sessions counter associated with a specific NAS. The -n switch is specified with the following parameter: ./ms_util -n nas_idwhere nas_id is the name of the NAS whose active session records you want to delete from the max-sessions counter. Example: To clear all sessions from NAS ciscoNAS, enter: ./ms_util -n ciscoNAS |
| -e | Deletes all records of active sessions from the max-sessions counter. The max-sessions count of all users is set to zero. Example: To clear the entire max-sessions counter, enter: ./ms_util -e |
Multiple delete operations can be specified on a single ms_util command-line. For example, the following ms_util command-line will delete session 103 of user john from NAS ciscoNAS, session 104 of user joe from NAS nasTWO, and clear all sessions from NAS nasTHREE:
./ms_util -u john,ciscoNAS,103 -u joe,nasTWO,104 -n nasTHREEThis is more efficient than running ms_util three times to perform the three deletes.
The AAA server metrics information in the csuslog file is generated when the config_metrics_enable variable is toggled on and the config_metrics_log_interval variable is set in the CSU.cfg file.
Typical AAA metric data output to a csuslog file, is shown below:
Mar 9 06:11:33 srv1 Total Authentications = 3176 APS = 0.0 Mar 9 06:11:33 srv1 TotalReqs TotalSec Mar 9 06:11:33 srv1 Accounting 3164 901.85 Mar 9 06:11:33 srv1 MaxSessions 3176 463.81 Mar 9 06:11:34 srv1 Profile 2974 248.26
Each log entry line displays the date and time of the entry and the name of the AAA server doing the processing. Other values displayed include:
Occasionally messages indicating "Severe SQL Error" might appear in the CiscoSecure ACS 2.2(3) Administration web pages. The accompanying on-line help might direct you to view the DBServer log files. Two types of DBServer log files are located in the $BASEDIR/logfiles directory:
The csdblog_date log file, located in the $BASEDIR/logfiles directory, logs error and warning messages from both the DBServer module and from the RDBMS (Oracle, Sybase, or SQLAnywhere) where you are storing your group and user profiles. A new csdblog_date log file is created every day.
Sample output is as follows for csdblog_98-Mar-5 (note that the first two lines are always present even if nothing else is; the other lines are the result of errors):
/*** Cisco Secure database server error log ***/
SEVERITY LEVELS ranges from 1 to 10 where 1=MINOR, 10=CATASTROPHIC
----------------------------------------------------------------------------
Thu Mar 05 09:33:07 PST 1998 Severity Level: 8 Error#0
Msg:DBInterface.execSqlUpdate:[insert into cs_user_profile ( user_na
me, profile_id, profile_ts, cycle_number ) values ( ?, 100000001, ?, 1 )
]{ SQLState: }, { Message: ORA-23326: object group MASTER-
MASTER is quiesced}, { Vendor Code: 23326}
Thu Mar 05 09:33:07 PST 1998 Severity Level: 8 Error#0
Msg:DBInterface.execSqlsInTran:{ SQLState: }, { Message: ORA-23326:
object group MASTER-MASTER is quiesced}, { Vendor Code: 23326}
Thu Mar 05 09:33:08 PST 1998 Severity Level: 8 Error#0
Msg:DatabaseWorker error: ORA-23326: object group MASTER-MASTER is q
uiesced
An example of a common DBServer-generated message that might appear in a csdblog_date log file is:
Wed Mar 04 12:51:49 PST 1998 Severity Level: 8 Error#0 Msg:DatabaseMgr:getAvailDBconn(): "Out of database resources error: The number of available connections to the Database has currently been reached. Please retry later"
If the preceding message appears frequently in the csdblog_date log file, increase the number of connections to the RDBMS (through the ConnectionLicense= parameter in the [Oracle] section of the CSConfig.ini file) or reduce the MaxConnection parameter in the CSU/libdb.conf file.
The DBServer module or RDBMS error messages that can be logged in a csdblog_date log file are ranked in order of severity from 1 to 10 (where: 1 = minor, 5 = moderate, 8 = severe, and 10 = catastrophic).
The default logging level is 8, which means that DBServer or RDBMS error messages with a severity of 8 or higher are logged in this file.
To change the level of logging for the purposes of troubleshooting or testing, edit the MinLogLevel = parameter in the $BASEDIR/config/CSConfig.ini file. For example, the following setting enables logging in the csdblog_date log file of moderate-or-higher severity messages.
MinLogLevel = 5
Lowering the logging level increases the amount of messages written to your daily csdblog_date log files.
Major DBServer module events, such as startup or shutdown, are recorded in the dbserver.log file, located in the $BASEDIR/logfiles directory. DBServer events too sudden and catastrophic to be logged in the csdblog_date log file, might be recorded in the dbserver.log file.
The system administrator can use the Java-based CiscoSecure Administrator advanced configuration program to enable the Filter attributes, Allow and Refuse. The Allow and Refuse attributes enable the system administrator to allow or refuse users or groups of users access to specific TTY ports or ranges of TTY ports on specific NASes.
Step 1 In the Java-based CiscoSecure Administrator advanced configuration program, select the user or group whose NAS and port access you want to filter and click the Profile icon.
Step 2 In the Options menu, click Filter and click Apply.
Step 3 Click the Filter icon and in the Permission menu, select either Allow or Refuse and click Apply.
Step 4 Click the Filter tab and fill out the following fields:
| Field | Description |
|---|---|
NAS | The IP Address or the FQDN of the NAS to which you want to allow or refuse access. Standard UNIX regular expression pattern matching syntax conventions apply. Example: To specify access to the NAS at IP address 10.8.1.176, enter: ^10\.8\.1\.176$ |
Port | The port on the specified NAS through which you want to allow or refuse access. Standard UNIX regular expression pattern matching syntax conventions apply. Example: To specify access through TTY ports, tty0, tty1, tty2,tty3, enter: ^tty[0-3]$ |
Remote Address (optional)
| Remote IP addresses through which you can allow or refuse access to the target NAS whose IP address or FQDN you specified in the NAS field. Standard UNIX regular expression pattern matching syntax conventions apply. Example: To specify access to the target NAS through remote IP address 10.98.12.180, enter: ^10\.98\.12\.180$
|
Step 5 Repeat Steps 2 through 4 for any other filter you want to specify.
Step 6 When you have specified all the filters to apply to this profile, click Submit.
In the following profile example:
user = boscotam {
service = shell {
default cmd = permit
default attribute = permit
{
profile_id = 137
profile_cycle = 1
password = clear "*************"
allow "^10\.8\.1\.176$" "tty([0-9]|10)$"
allow "^10\.8\.1\.176$" "tty(2[1-9]|30)$"
refuse "^10\.8\.1\.176$" "tty(1[1-9]|20)$"
refuse "^171\.68\.118\.238$" ".*"
refuse "apps-comm1\.xyz\.zcorp\.com" ".*"
}
The Java-based CiscoSecure Administrator advanced configuration program now allows you to apply attributes from additional RADIUS dictionaries optimized for compatibility with Cisco IOS Releases 11.1, 11.2, 11.3 and Ascend version 5.
In addition to the original RADIUS-Ascend, RADIUS-Cisco, RADIUS-IETF options, the CiscoSecure Administrator options menu now provides the following additional RADIUS dictionary options:
The RADIUS-Cisco11.3 dictionary includes Cisco's set of vendor-proprietary extended RADIUS attributes. To take full advantage of this version, configure the associated NAS as follows:
radius-server host hostname|ip-address non-standard
radius-server configure-nas
For a description of the vendor-proprietary attributes themselves, see "RADIUS Vendor-Proprietary Attributes," in the appendix "RADIUS Attributes" in the document Security Configuration Guide, accessible at the Cisco documentation web site at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/ scprt6/index.htm
You can edit the DBPollInterval= parameter in the [ProfileCaching] section of the $BASEDIR/config/CSConfig.ini file to modify the CiscoSecure profile caching interval. The syntax is:
DBPollInterval=caching_interval
where caching_interval specifies the interval, in minutes, between profile cache updates from the RDBMS. For example, the default setting of every 30 minutes is specified as:
DBPollInterval=30
Seconds can be specified as fractions of minutes. For example:
DBPollInterval=1 1/2
DBPollInterval=15/60
If you change the default value of the Netscape FastTrack Server TCP/IP port number from 80 to some other value, you must perform the following additional steps to ensure continued operation of the Java-based CiscoSecure Administrator advanced configuration program.
Step 1 On the CiscoSecure ACS server, locate the $BASE/FastAdmin/turbo.conf file and change the following line:
NS_PATH=machine_name/cs/to
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.
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 signed by either Netscape or VeriSign. VeriSign will sign your keys for a fee, provided you comply with certain requirements.
To enable SSL on your web server, follow these steps:
Step 1 Log in to the FastTrack Server as the administrator (root privileges). Enter:
You are prompted for a username and password.
Step 2 Enter the username and password, for example:
The Netscape Server Selector window opens.
Step 3 Click the name of your Netscape FastTrack Server.
Step 4 From the command buttons at the top of the window, click Encryption.
Step 5 On the left side of the window, click Generate Key.
A help window called Generating a key pair opens.
Step 6 Follow the online instructions to generate a server key pair.
Step 7 Click Request Certificate.
The online form called Request a Server Certificate opens.
Step 8 Complete the online form, then click OK.
Step 9 Request a certificate from a Certification Authority (such as VeriSign at www.verisign.com) and obtain a signed key.
Step 10 When you receive the server certificate, click Install Certificate from the Server Manager window.
The online form called Install a Server Certificate opens.
Step 11 Complete the online form, then click OK to install the server certificate.
Step 12 On the left side of the window, click On/Off to enable encryption.
New TACACS+ and RADIUS support for caller ID allows you to base profiles on the calling number, rather than the username being passed. Identifying users by their telephone number is especially useful for accounting purposes because you can directly bill charges according to the calling number.
To configure support for caller ID, create a new user profile and enter a designated telephone number instead of a username.
The following example shows a user profile configured for caller ID:
user = 5551212
password = chap01
In this case, if an unknown user dials in to 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 the caller ID feature, see the descriptions of the CSU.cfg variables, config_callerid_enable and config_defaultuser_enable in "Additional CSU.cfg Variables,".
The profile attribute Privilege - Web will accept a blank password (input as a blank space in the password field) as valid.
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, 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 and the PAP at the password prompt. for example:
username: pameagan*546323
password: ********
It is now possible, however, to assign TACACS+ attributes in such a way as to enable PPP and PAP protocol OTP users to log in with more conventional entries, entering username at the username prompt and entering the OTP at the password prompt. For example:
username: pameagan
password: 546323
Using the Java-based CiscoSecure Administrator advanced configuration program, configure your PPP and PAP protocol OTP users with TACACS+ attributes. Use the main options menu to configure your users with TACACS+ attributes as before (for example: Service-PPP, Password-PAP, Password-crypto):
CiscoSecure ACS 2.2(3) for UNIX supports new parameters in the [AccountingMgr] section of the $BASEDIR/config/CSConfig.ini file that permit you to configure memory buffering for ACS accounting. The parameters and default settings are listed below:
The buffering of accounting records in memory carries an inherent risk of record loss in the unlikely event that the DBServer terminates ungracefully or is unable to write to the RDBMS for some other reason. To minimize this risk, you can set the BufferAccountingPackets and ProcessInMemoryMaxSessionInfo parameters to disable to stop accounting record buffering; however, doing so will adversely and substantially affect accounting performance.
A problem with file permissions in the SPARCstation's /tmp directory might prevent the Netscape FastTrack server module that was installed with CiscoSecure ACS from starting when you attempt to start the CiscoSecure ACS. If this happens, administrators and users attempting to access the CiscoSecure ACS Administration or User password web pages will be unable to do so.
A check of the $BASEDIR/logfiles/cs_startup.log file might display the following message:
seminit failed (libsec code -8187)
This message is caused by the FastTrack server not having read, write, and execute permissions to the SPARCstation /tmp directory.
To remedy, set the SPARCstation /tmp directory file permissions to "777" and restart the CiscoSecure ACS.
If you use CiscoSecure command-line scripts or CSimport tool to add a large number of CiscoSecure users (5,000 or more) to a Sybase CiscoSecure RDBMS, you need to run the Sybase ISQL utility to update the CiscoSecure-related tables after the command-line or import operation.
At the affected database site, run the ISQL utility and update the CiscoSecure-related tables. Enter:
isql -UAdminID -PAdminPasswd -SSybaseName
> update statistics cs_profile
> go
> update statistics cs_user_profile
> go
> update statistics cs_profile_blob
> go
> update statistics cs_password
> go
> update statistics cs_privilege
> go
> update statistics cs_group_profile
> go
where:
AdminID is the login name ISQL uses for connecting to SQL Server.
AdminPasswd is the password for connecting to SQL Server.
SybaseName is the name of SQL Server whose database you want to update.
Use the following procedures to increase GUI performance on Netscape Navigator browser.
Step 1 Bring up the Netscape Navigator Cache settings:
The Memory Cache dialog box opens.
Step 2 In the Memory Cache field, increase the number from the default (1024 kilobytes) to 8000.
Step 3 In the Disk Cache field, increase the number from the default (5000 kilobytes) to 20000.
Step 4 Click OK.
The increased memory and disk cache take effect immediately.
Step 1 Bring up the Netscape Navigator Cache settings.
The Memory Cache dialog box opens.
Step 2 Click Clear Memory Cache Now.
Step 3 Click Clear Disk Cache Now.
Step 4 Click OK.
The memory and disk cache are cleared immediately.
When running the administration GUI under Netscape Navigator, the virtual memory used by Netscape constantly increases. There are no known issues associated with this behavior.
The security of your network can be compromised in many ways beyond the data exchange between the NAS and the CiscoSecure ACS. This section identifies areas that are potential security hazards and gives you advice on what you can do to protect these key areas, or security holes, against potential intruders.
Keep your CiscoSecure server and NASes in a locked room. Restrict access to that room and the servers within it.
Unless physically protected, intruders can attack your network at several points. Perhaps most damaging is the possibility that an intruder can approach a security server and remove its disk drive for later analysis. Additionally, when security servers are physically accessible, intruders can potentially boot the server from a CD-ROM or floppy disk, then mount the hard disk from the system, and finally change the root password. With a new root password known only to the intruder, the potential for damage is limitless.
In other cases, the intruder might disrupt service by turning off the server or disconnecting it from the network. A "denial of service" attack might even involve destroying the security server or its disk; this is another scenario where keeping good backups can reduce downtime.
If at all possible, keep the local telephone closet locked. When the telephone lines going into a NAS are adequately secured, wire-tapping of telephone lines or monitoring of keystrokes becomes difficult (although not impossible).
Keep remote access to security servers as restricted as possible. Even with security servers physically locked down, attacks can be launched remotely by intruders if they can access the servers through the network. Many software bugs have eventually turned out to be security holes. For this reason, you should avoid using any unnecessary services on the security server that might potentially have as-yet-unknown security holes.
Most networks have large numbers of unencrypted passwords and other data flowing over them. As such, local users are able to "snoop," or easily extract, data flowing over broadcast technology networks such as Ethernet. At the very least, consider using secure methods of logging in and manipulating security configurations (for example, use Kerberized and encrypted rlogin access, SSL browsers, or dedicated and physically secured serial lines).
Do not allow local users to access security servers, even if the local users lack any privileges to change the configurations. This helps prevent exploitation of potential security holes that might exist but are generally not known.
Construct passwords that are fairly long (at least 8 characters) and consist of letters (uppercase and lowercase) and numbers. Confirm that the password cannot be easily guessed by people with familiarity with the local organization or personnel. Password-guessing attacks are the easiest and most common type of network intrusion. The easier a password is to guess, the faster an attacker can gain access to protected data.
Even well-chosen passwords are easily captured if sent in cleartext over broadcast media (such as Ethernet). Normally, protocols such as Telnet and rlogin do not encrypt passwords that are sent over the network although the destination system might encrypt those passwords upon arrival.
Use different passwords for the security servers and other systems, especially ones that can be accessed through unencrypted protocols. Some protocols, such as Kerberized Telnet, do not send the password over the network in cleartext, but subsequent data is still unencrypted. Consequently, while these protocols limit exposure, they do not entirely restrict exposure.
Confirm that your installation of CiscoSecure ACS is conducted in one session. Do not interrupt the installation. Similarly, do not leave your server unattended if you are conducting subsequent configurations, such as adding new users or support for a new one-time password card. An intruder can potentially gain sensitive information during configurations and use the information later.
Do not install CiscoSecure ACS over an unsecure network; instead, install CiscoSecure ACS at the system console.
When providing configuration information to anyone (even technical support personnel), remove sensitive information such as passwords. Replace sensitive information such as password strings with "XXXXXX."
Do not use the Netscape FastTrack Server software (which came bundled with CiscoSecure ACS) to serve any web pages that are not part of CiscoSecure ACS.
Use SSL for encrypted connections to the Netscape FastTrack Server. This provides a high degree of security. Users can use their own web browsers to connect to the CiscoSecure ACS database to change their own passwords. As such, all of the data traffic is vulnerable and should be encrypted.
This section identifies issues with CiscoSecure ACS 2.2(3) and related information. Some of these issues will be addressed in a subsequent release.
The following issues have 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.05 or use Netscape Navigator 3.04 or 4.04.
The Security Socket Layer (SSL) feature of the Navigator 4 for Solaris browser does not support the Java-based CiscoSecure Administrator advanced configuration program. To access the CiscoSecure Administrator using the SSL feature, do so through Netscape Navigator or Netscape Communicator for Windows 95 or Windows NT. [CSCdj68773]
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]
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 that provided by local telephone services. In addition, CiscoSecure ACS is a client/server product that includes a full relational database management system, so you might experience wait time as profiles are written to and from the database.
To change the username and password on your FastTrack Server, perform the following steps:
Step 1 Log in to FastTrack as the administrator:
You see a screen requesting your username and password.
Step 2 Enter your administrator username and password to gain access to the Web Server Administration section.
Step 3 Click the Configure Administration box.
Step 4 Click the Access Control line.
Editable fields for username and password display.
Step 5 Replace the username and password as necessary.
In cases where Oracle Master-to-Master or Sybase Peer-to-Peer database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same time period between database replication processes.
If the same user profile is updated at two different sites within the same time period between replications, the user profile edits at both sites will neither be replicated nor 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]
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 IDs.
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:
We do 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 carry out large scale database growth and update operations, we recommend use of the Oracle Enterprise or Sybase Enterprise RDBMS engines.
CiscoSecure ACS installations using versions 7.3.3 and 7.3.2 of the Oracle client modules SQL*Net and TCP/IP protocol adapter sometimes experience profile retrieval and DBServer module failure problems under heavy usage. To forestall these problems, install the SQL*Net and TCP/IP protocol adapter client modules that come with Oracle 7.3.4 or higher.
The Oracle 7.3.4 upgrade is available free to all customers with a valid support contract. [CSCdj78312] [CSCdj86330]
Failure to maintain sufficient available disk space on the SQLAnywhere, Oracle, or Sybase database server storing records for the CiscoSecure ACS can result in a general warning message and a failure to update CiscoSecure accounting records. To prevent such failures, the system administrator should:
When the Oracle trace file exceeds 5 MB (as may happen under frequent and heavy loads), the Oracle server might occasionally dump core data and abort. This is a known Oracle problem (ID Number: 510778) that is remedied with Oracle version 8.0.4.
If this condition is causing problems, Oracle recommends that you disable Oracle tracing as follows:
Step 1 Go to the $ORACLE_HOME/otrace/admin directory of your Oracle server.
Step 2 Delete the existing process.dat and regid.dat files and recreate them to the default size:
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]
Loading a large CiscoSecure group profile (20,000 users or more) from within the Java-based CiscoSecure Administrator advanced configuration program might lock up that program. If you have to administer large group profiles, use the CiscoSecure ACS 2.2(3) Administration web pages or the CiscoSecure command-line interface (CLI). [CSCdk25587]
The RADIUS Password-Lifetime attribute 208 is not supported by CiscoSecure. If a user changes his or her password before the specified password expiration date, the password expiration date is supposed to increment by the number of days specified by RADIUS attribute 208; however, the password expiration date does not increment and remains unchanged. [CSCdk14530]
CiscoSecure ACS 2.2(3) for UNIX has not been tested with any Safeword version later than 4.3. Used in conjunction with Safeword 4.4.1, CiscoSecure cannot configure hard or soft tokens. [CSCdk3161]
Failed login attempts involving CiscoSecure token caching and the unknown_user feature might cause leakage of small amounts of system memory. The system administrator should monitor memory usage at the ACS and possibly restart the ACS every few months. Because memory leakage only occurs on login failures, the amount might not even be noticeable. [CSCdk19520]
The CiscoSecure Command Line Interface (CLI) and CSImport tools do not accept the single backslash character ( \ ) as valid input. CLI commands or CSImport operations that include single backslash characters as input will fail.
An exception to the above restriction is the use of the combined backslash and n character string (\n) (as noted on page C-4 of the CiscoSecure ACS 2.2.2 for UNIX User Guide). The \n character string is recognized by the CLI AddProfile command syntax as a line break command when used in conjunction with the -a switch input to specify additional free-formatted profile information. [CSCdk24340]
If you use the Member>View option on the web-based CiscoSecure Administration web pages to enter the name of a non-existent group and then click Group, and Submit Query, the resulting page informs you that the group you queried for does not exist; however, it also displays an "Add a User" profile icon that you can click on to display an "Add a User" page, falsely implying that you can add a user profile to a non-existent group. Any data entered on this page is meaningless and will not be added to the CiscoSecure profile database. You cannot add a user profile to a non-existent group. [CSCdk14088]
The ACS has once been witnessed to perform an automatic restart after it has been subject to five hours of stress testing. The test placed a continous load of 20 or more authentications per second on the ACS. Oracle 8.0.4 was the database used during the test. Should the ACS begin to show automatic restart symptoms under similar conditions, you can use the following solution to solve the problem. It involves stopping the ACS, substituting an older driver for the new one that was selected during the ACS installation process, and restarting the ACS. [CSCdk27794]
Step 1 Log in to the ACS.
Step 2 Type /etc/rc0.d/K80CiscoSecure to stop the ACS.
Step 3 Type $BASEDIR/weblogic/lib/solaris/oracle to change directories. In this directory, the following link to the new driver can be seen.
Step 4 Type rm libweblogicoci26.so to remove the link.
Step 5 Type ln -s libweblogicoci26.so.7 libweblogicoci26.so to create the new link. The link using the old driver should now look like the following.
Step 6 Type /etc/rc.2d/S80CiscoSecure to start the ACS.
If you are attempting to upgrade from CiscoSecure 2.2.2 to 2.2(3) in an existing replication environment and your environment includes non-updatable sites, then when you upgrade the CiscoSecure software on the non-updatable sites, you will receive an error message at the end of the upgrade process stating that the installation failed. This occurs because the CiscoSecure tables that were set up for replication cannot be written to except by the replication process.
The workaround for this problem is to make sure that you have successfully upgraded CiscoSecure on your Master Definition site. Ignore the error message received on the non-updatable site(s). Once you replicate, the tables that were not able to be updated will become updated from the Master site by the replication process.
This section addresses errors in the CiscoSecure ACS 2.2.2 for UNIX User Guide and information that was not available before the user guide was printed.
The following information supplements the copyright information in the user guide:
CiscoSecure ACS 2.2(3) supports asynchronous database replication among multiple CiscoSecure ACS sites that use the Oracle 7.3.3 and later or Sybase 11.02 and later database engines to store their profile information. Two recommended database replication scenarios are:
This appendix provides example procedures for setting up Oracle and Sybase database systems to carry out replication of the CiscoSecure database among multiple CiscoSecure ACS sites.
Figure 1 illustrates an example of Master-to-Snapshot or Primary-to-Replicate database replication as applied to multiple CiscoSecure ACS sites. In this scenario, all administrative changes to the user profile database are made through the web-based console to one ACS site. Then, at specified time intervals, those changes are replicated to all other sites on the network, enabling the ACSes to provide their authentication, authorization, and accounting services based on a common set of user profile data.
Figure 2 illustrates Master-to-Master or Peer-to-Peer database replication as applied to multiple CiscoSecure profile database sites. In this scenario, local administrative changes to the user profile database can be made through the web-based consoles at two or more ACS peer sites. Then, at specified time intervals, each of these peer sites communicate their local changes to all other sites on the network. As with Master-to-Snapshot replication, the end result is that the ACSes are able to provide their authentication, authorization, and accounting services based on a common set of user profile data.
The example procedures in this section use the Oracle Net8 Easy Config (or the Oracle 7 SQL Net Easy Config), Security Manager, Schema Manager, SQL*Plus, and Replication Manager programs run on a Windows 95 workstation console to integrate Oracle database replication with multiple CiscoSecure ACSes.
 | Caution Implementing Oracle database replication requires an in-depth knowledge of Oracle tools and database structure. Integrating database replication with the CiscoSecure product based on the following example procedures should be carried out by experienced Oracle database administrators (DBAs) only. |
For specific instructions on how to use the above Oracle programs, please refer to Oracle manuals and on-line help.
For each service that you created in Step B, use the Oracle Security Administrator to create a special user with special privileges to control database replication.
| Caution This user must not be the Oracle user that you specified as in charge of the DB account for CiscoSecure data during CiscoSecure installation. |
Create two-way links between the databases. For each database instance, do as follows:
If you are configuring Master-to-Snapshot replication, follow the steps in this section. If you are configuring Master-to-Master replication, skip this section and go to "F. If You are Configuring a Master-to-Master Database Replication Scenario,".
Step 1 Using the SQL*Plus utility, log in to each database instance that you want to be a Snapshot site.
Step 2 Using the Oracle Replication Manager, create a database connection for each database connection service that you set up in Step B.
Step 3 Using the Oracle Replication Manager, select the database connection that you want to be the Master Definition site and create and configure the master group on this site as follows:
Step 4 Using the Oracle Replication Manager, select and set up each database connection that you want to be a Snapshot site as follows:
Step 5 At the Master Definition database site, change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
CSdbTool cache_trigger
Step 6 At each Snapshot database site, change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
CSdbTool cache_trigger_snap
Step 7 Before you create any new users, configure the Snapshot sites to prevent duplicate user profile names. At each Snapshot site, enter the following command:
Step 8 Edit the initsid.ora configuration file. At each Oracle site, do the following:
compatible = 7.1.0.0compatible = 7.3.0.0Step 9 At the CiscoSecure ACS for the Master site, restore the listings for the CiscoSecure servers installed at Snapshot sites:
If you are configuring Master-to-Master replication, follow the steps in this section. If you are configuring Master-to-Snapshot replication, ignore this section. See "Precautions Running Oracle Database Replication and CiscoSecure,".
Step 1 Using the SQL*Plus utility, log in to each database instance that you want to be a Master Destination site:
| Caution Remember, delete the above tables from Master Destination sites only. |
Step 2 For each database connection service, create a surrogate replication administrator.
| Caution This user must not be the Oracle user that you specified as in charge of the DB account for CiscoSecure data during CiscoSecure installation. |
Step 3 Using the SQL*Plus utility, assign the appropriate privileges to the database surrogate replication administrator at each Oracle site:
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:
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 the following:
compatible = 7.1.0.0Step 14 Restart the Oracle server to have the changes to the inisid.ora file take effect.
Step 15 At the CiscoSecure ACS for the Master Definition site, restore the listings for the CiscoSecure servers installed at the Master Destination sites.
In cases where Oracle Master-to-Master (or Master-to-Updateable-Snapshot) database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.
If updating of the same user profile at two different sites within the same interval between replications occurs, the user profile edits at neither site will be replicated or reconciled. The user profile will remain with unreconciled settings at both sites, and the following Oracle error message will appear at both sites within the "Local Errors" section of the Oracle Replication Manager tree:
ORA-01403 no data found error
The above error should rarely occur, because, in practice, no more than one administrator, administering from one CiscoSecure ACS site should be authorized to administer any one user profile anyway.
However, if this error does occur, you must fix the unreconciled user profile at both sites as follows:
Step 1 Use the web-based CiscoSecure ACS Administration web pages or the Java-based CiscoSecure Administrator program to do the following:
(a) Examine the user profile settings at each site. Determine which user profile is the one you want replicated and note the settings.
(b) Delete the user profile at both sites.
(c) At one of the sites, create a new user profile with the same name as the profile you just deleted.
(d) Manually configure this user profile with the settings that you wanted.
Step 2 Use the Oracle Replication Manager to force replication, or wait until the next scheduled replication.
The settings for the new user profile will replicate throughout the system.
The following example procedures use the Sybase RS INIT, and rsmgen utilities run on the UNIX server, and Sybping, and Replication System Manager, running on a Windows 95 workstation console, to integrate Sybase database replication with multiple CiscoSecure ACSes.
| Caution Implementing Sybase database replication requires an in-depth knowledge of Sybase tools and database structure. Integrating database replication with CiscoSecure based on the following example procedures should be carried out by experienced Sybase database administrators (DBAs) only. |
For specific instructions on how to use the above Sybase programs, please refer to Sybase manuals and on-line help.
Sybase supports two types of database replication: Primary-Server-to-Replicate-Server and Peer-Server-to-Peer-Server.
To carry out database replication, Sybase requires that you install a Replication Server at one of your Sybase database sites and a Replication Server Manager client module at a PC console.
Step 1 At your Primary site, make sure that the Sybase SQL server or Adaptive server module is installed and running.
Step 2 Install the Replication Server and Replication Server Manager modules.
Step 3 Install the Sybase SQL Manager and Replication Manager Client tools on a PC console.
The Sybase Replication Server executes replication among the Sybase database sites. Set it up by using the Sybase RS INIT program following the procedures outlined in your Sybase documentation. RS INIT settings that require specific input in order to integrate Sybase replication of the CiscoSecure database are noted below:
Step 1 Specify the Replication Server Information settings. Except for the settings listed below, accept the default values:
Step 2 Specify the Replication Server Interfaces Information settings. Except for the settings listed below, accept the default values:
Step 3 Accept the default ID Server Information settings.
Step 4 Specify the Replication Server System Database Information settings. Except for the settings listed below, accept the default values:
Step 5 Specify the RSSD Device Information settings. Except for the settings listed below, accept the default values:
Step 6 Specify the Disk Partition Information settings. Except for the settings listed below, accept the default values.
Step 7 Accept all default values for the Remote Site Connections Information settings.
At each CiscoSecure database site run, RS INIT to integrate the CiscoSecure database into the Sybase replication system. Set it up by using the Sybase RS INIT program following the procedures outlined in your Sybase documentation. RS INIT settings that require specific input in order to integrate Sybase Replication of the CiscoSecure database are noted below:
Step 1 Specify the Replication Server Information settings. Except for the bulleted settings listed below, accept the default values:
Step 2 Specify the Database Information settings. Except for the bulleted settings listed below, accept the default values:
Step 3 At Primary and Peer database sites only, accept all the default Database Log Transfer Manager settings.
Step 4 At Primary and Peer database sites only, configure the LTM Interfaces Information settings. Except for the bulleted settings listed below, accept the default values:
Step 5 Accept the settings. Note the logfile location on exit.
Set up one Replication Services Manager Server as follows:
Step 1 At the Primary server, use the Sybase DSEDIT utility to create an RSM server entry in the Sybase Interfaces file.
Step 2 In the $SYBASE/Install directory, run the rsmgen utility.
Step 3 When prompted for the RSM Server name, specify the name you entered in the Interfaces file.
The rsmgen utility creates a file: RUN_rsmfilename.
where rsmfilename is the name you specified while running rsmgen.
Step 4 Run the RUN_rsmfilename file in background mode. Enter:
./RUN_rsmfilename &
Step 1 Move to the Windows 95 or Windows NT workstation on which you installed the Replication Services Manager client and ping the hosts running all the Sybase servers involved in database replication to test the console-to-Sybase server TCP/IP connections.
Step 2 If the pings are successful, use the Windows-based SQLEDIT program to generate an Interface file on the PC. Point to the IP addresses and TCP/IP ports of the SQL or Adaptive Server, Replication Server, LTM server, and RSM server.
Step 3 Use the Sybping utility to ping the Adaptive Server, Replication Server, LTM server, and RSM server modules and confirm the console-to-server Sybase connections.
Step 4 Start the Windows-based RSM Manager.
Step 5 Select the File>New RSM Domain menu command.
Step 6 To create an RSM domain for your CiscoSecure profile databases, do the following:
Step 7 On each Primary server or Peer server in the RSM Domain, configure replication definitions for each of its tables as follows:
If you are configuring Primary-to-Replication server replication, follow the steps in this section. If you are configuring Peer-to-Peer replication, skip this section and go to "H. If You are Setting Up Peer-to-Peer Replication,".
Step 1 For each Replicate server in the RSM domain, configure subscriptions to each of the six replication definitions configured in Step F:
Step 2 At each of the CiscoSecure database sites, enable profile caching. Change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:
Step 3 At the CiscoSecure server for the Primary site, restore the listings for the CiscoSecure servers installed at the Replicate sites:
If you are configuring Peer-to-Peer replication, follow the steps in this section. If you are configuring Primary-to-Replicate server replication, ignore this section.
Step 1 Decide which of your Sybase sites will be the initial source Peer site.
When the first replication is run the initial source Peer site will be the site containing the original profile data structures that will be replicated to all the other sites.
All the other sites will be secondary Peer sites.
Step 2 At each secondary peer site, delete the current CiscoSecure profile records.
Start the Sybase ISQL utility and use the delete command to empty the current CiscoSecure profile records. Enter:
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:
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:
Step 7 Restart the CicsoSecure ACS at each site if it is running.
Step 8 At the CiscoSecure ACS for either the initial or a secondary Peer site, restore the listings for the CiscoSecure servers installed at the secondary Peer sites:
In cases where Sybase Peer-to-Peer database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.
If updating of the same user profile at two different sites within the same interval between replications occurs, the user profile edits at neither site will be replicated or reconciled. The user profile will remain with unreconciled settings at both sites.
In practice, this error is unlikely to occur for two reasons:
However, if the above error does occur, fix the unreconciled user profile as follows:
Step 1 Use the web-based CiscoSecure ACS Administration web pages or the Java-based CiscoSecure Administrator program to do the following:
(a) Examine the user profile settings at each site. Determine which user profile is the one you want replicated and note the settings.
(b) Delete the user profile at both sites.
(c) At one of the sites, create a new user profile with the same name as the profile you just deleted.
(d) Manually configure this user profile with the settings that you wanted.
Step 2 Wait until the next scheduled replication.
The settings for the new user profile will replicate throughout the system.
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
.
|
|