|
|
Four features are provided with Cisco Secure ACS 2.3 for Windows NT Server (CiscoSecure ACS):
A command-line utility, CSUtil.exe, is also provided. For information on CSUtil.exe see "CiscoSecure ACS Command-Line Database Utility."
These utilities help automate the process of keeping your CiscoSecure ACS database and network and system configurations current.
The system backup and system restore features help automate the process of updating your CiscoSecure ACS system configuration. These features allow you to back up your system information to a backup file and restore it from any such file on the local hard drive. This minimizes downtime if the system information is corrupted or misconfigured.
Database replication is used to copy the CiscoSecure ACS database information to another CiscoSecure ACS for backup purposes.
RDBMS synchronization allows CiscoSecure ACS to tightly integrate with other RDBMS data sources. It is not normally used to build fault-tolerant multiserver installations; however, in some configurations, it can be used for this purpose.
To use these features, you must enable them in the Interface Configuration: Advanced Options window.
During the replication, synchronization, backup, and restore processes, authentication, authorization, and accounting (AAA) services are halted momentarily. For replication and synchronization, services are stopped on both machines, although not at the same time. Service is normal while the replication set is being transmitted between servers.
The System Backup process backs up your system information to a backup file on the local hard drive and restores it from any such file. This minimizes downtime if the system information is corrupted or misconfigured. It is a good idea to copy the files to another system's hard drive in case the primary system's hardware fails.
Assuming that you installed CiscoSecure ACS on the c: drive, the default directory for the backup files is:
c:\directory\CSAuth\System Backups
where directory is the directory in which you installed CiscoSecure ACS. You can change the location of the backup files in the System Configuration: ACS Backup window.
The ACS System Backup utility backs up the CiscoSecure ACS user database and CiscoSecure ACS Registry information. The user database backup includes all of the user information, including username, password, and authentication information. The Windows Registry information includes any system information that is stored in the Windows Registry, such as Network Device Group information, NAS configuration, administrator accounts, and so on.
You can choose to manually back up the CiscoSecure ACS system or establish a regular schedule, either every X minutes or at selected days and times. For instructions on establishing schedules, see "Step-by-Step Configuration for CiscoSecure ACS."
You can configure the number of backup files to keep and the number of days after which these files are deleted. The more complex your configuration and the more often you back up the system, the more diligent you need to be about clearing out old databases from the server's hard drive.
When a system backup takes place, whether it was manually generated or scheduled, the event is logged in the Administration Audit report and the ACS Backup and Restore report. You can view any of the last several reports in the Reports and Activity window of CiscoSecure ACS.
The System Restore feature allows you to restore your system configuration from any CiscoSecure ACS-generated backup file on the local hard drive. This minimizes downtime if the system information is corrupted or misconfigured.
The ACS System Restore utility restores the CiscoSecure ACS user database and CiscoSecure ACS Windows Registry information from a file on the hard drive that was created during ACS System Backup. You can either restore from the latest backup file, or, if you suspect that the latest backup was incorrect, you can select an earlier backup file to restore from. Backup files are listed in the System Configuration: ACS Backup window in the Select Backup to Restore From section. Files are listed in chronological order, with the newest file at the top of the list.
Assuming that you installed CiscoSecure ACS on the c: drive, the default directory for the backup files is:
c:\directory\CSAuth\System Backups
where directory is the directory in which you installed CiscoSecure ACS.
Filenames are in the following format:
dd-mmm-yyyy hh-nn-ss.dmp
where:
dd is the date the backup started
mmm is the month, abbreviated in alpha characters
yyyy is the year. Note that these files are year-2000 compliant.
hh is the hour, in 24-hour format
nn is the minute
ss is the second at which the backup started
For example, a backup that was started on October 13, 1998, at 11:41:35 am would generate a file named:
13-Oct-1998 11-41-35.dmp
If you are not sure of the location of the latest backup file, you can check their location in the System Configuration: ACS System Backup window.
To change the directory location from which to restore, in the System Configuration: ACS Restore window, double-click in the Directory text box and enter the name of the applicable directory. The directory must already exist; CiscoSecure ACS will not create it for you. Then click OK.
You can select the components to restore: the user and group databases, the system configuration, or both.
When a system restore takes place, the event is logged in the Administration Audit report and the ACS Backup and Restore report. You can view any of the last several reports in the Reports and Activity window of CiscoSecure ACS.
Files are in comma-separated-value (csv) format, so you can import them into spreadsheets using most popular spreadsheet application software. See your spreadsheet software manufacturer's documentation for instructions.
Files are listed in chronological order, with the newest file, Backup and Restore.csv, at the top of the list. Older files are named in the following format:
Backup and Restore yyyy-mm-dd.csv
where:
yyyy is the year the backup was started. Note that these files are year-2000 compliant.
mm is the month of the backup, in numeric characters
dd is the date of the backup
For example, a log file that was generated on October 13, 1998, would be named:
Backup and Restore 1998-10-13.csv
Database Replication helps make your AAA environment more fault-tolerant. Database Replication helps create mirror systems of the CiscoSecure ACS by duplicating parts of the primary server setup to one or more client systems. These mirror systems can then be used as backup or secondary servers if the primary system fails or is unreachable.
Database Replication allows you to:
Do not confuse Database Replication with System Backup. Database Replication is not a complete replacement for System Backup. While dealing with many of the same issues (protection from partial or complete server loss), the two processes deal with the issues in a different way.
System Backup archives data into a format that you can later use to restore the configuration if the system fails or the data becomes corrupted. The backup data is stored on the local hard drive and can be copied and removed from the system for long-term storage. You can store several generations of the database backup.
Although unlikely, it is possible that a corrupted database could be propagated to the backup clients. Cisco therefore strongly recommends that if you are using CiscoSecure ACS in mission-critical environments, you implement an adequate backup plan, whether or not you use Database Replication. See the "ACS System Backup" section and "ACS System Restore" section or "CiscoSecure ACS Command-Line Database Utility," for more information on backing up the system or database.
Database Replication provides fairly comprehensive replication of the CiscoSecure ACS servers, but it does not replicate all of the CiscoSecure ACS setup. Because CiscoSecure ACS relies on several communication dynamic link libraries (DLLs), Database Replication does not include external authentication sources. Because the system administrator manually determines which DLLs are installed, Database Replication cannot rely on the necessary DLLs being present. Use the System Backup utility to back up these parts of the CiscoSecure ACS configuration.
Configure the following items for Database Replication in the CiscoSecure ACS HTML user interface:
Database Replication allows you to select only some of the configuration data elements to be transferred to the client system. However, to create a mirror system, all items must be selected.
You can select the following items to be replicated:
For each item, there are 2 check boxes, one labeled Send and the other labeled Receive. For configuration of the primary (source) system, only the Send check box is relevant; the Receive check box refers to the Client setup.
You can configure Database Replication to perform replication in one of the following ways:
To select the desired mode of operation, check the appropriate button and configure the parameters as appropriate.
If mirroring the entire database with another CiscoSecure ACS might send confidential information, such as Distribution Tables, from the primary AAA server's site, you can configure Database Replication to send only a specific category of database information.
This setting can have important implications for overall AAA service performance; you as administrator should be aware of the trade-offs in system performance. With shorter frequencies, the backup AAA server will be more up-to-date with the primary server, allowing for a more current backup if the primary system fails, and a more current view of the CiscoSecure ACS user database. However, the greater the currency, the higher the load on the overall AAA system and network environment. First, because the data is being transferred more often, the network traffic load is much higher. Second, the processing load on the synchronizing systems is increased. This process consumes system resources, and the more often the process is repeated, the greater the impact on the AAA server's authentication/authorization/accounting performance.
This issue is more apparent with very large databases, very dynamic databases (frequent changes are made to the database), or both. Database Replication is a non-incremental, destructive backup. In other words, it completely replaces the database and configuration on the client system every time it is run. Therefore, if the database being transferred is very large, the amount of data being transferred can be substantial, and the processing overhead can also be large.
Database Replication supports replication to one or more target or client CiscoSecure ACS systems. To select client systems for replication, follow these steps:
Step 1 Click System Configuration: CiscoSecure Database Replication.
Step 2 In the Replication Partners section in the AAA Servers column, click the name of the system you want to be the target.
Step 3 Click the right arrow button to move the selection into the Replication column.
Step 4 Repeat this process as required.
To deselect a replication target, reverse the above procedure, using the left arrow button to move the server name into the AAA Servers column.
Database Replication uses a sophisticated client/server relationship to provide strong security and control to sites using this feature. For Database Replication to work, both the server and client must be correctly configured; if the client is not configured to receive replication instructions, it rejects them. The client's receive configuration is set using the same user interface windows as the server. To configure a client to receive replication, follow these steps:
Step 1 Click System Configuration: CiscoSecure Database Replication.
Step 2 In the Replication Components section, check the Receive check box for each of the fields in which you want data to be accepted.
Step 3 Configure the information in the Replication Scheduling section to match the information configured on the primary AAA server.
Step 4 In the Replication Partners section, in the Accept Replication From drop-down box, click the name of the primary AAA server.
Because system replication is a critical process, Database Replication provides visual alerts and logging to notify the system administrator of any problems that occurred during a replication event.
If replication fails, CiscoSecure ACS displays an error message in red at the top of the Database Replication window. Besides notifying you of errors, the message also displays the error code generated by the last unsuccessful run and suggests you check the error log messages generated for previous failures. To acknowledge and close the message, click OK.
Events are logged in two Database Replication files: the Windows NT Event Log and a dedicated CSV log file. All events are logged, whether they are successful or not. To view the Windows NT Event Log, use the Windows NT administration utilities. To view the Database Replication Event log, click Reports and Activity: Database Replication and click the name of the file to view. You can also import the csv files into spreadsheets using most popular spreadsheet application software. See your spreadsheet software manufacturer's documentation for instructions.
Files are listed in chronological order, with the newest file, Database Replication.csv, at the top of the list. Older files are named in the following format:
Database Replication yyyy-mm-dd.csv
where:
yyyy is the year the replication was started. Note that these files are year-2000 compliant.
mm is the month of the replication, in numeric characters
dd is the date of the replication
For example, a log file that was generated on October 13, 1998, would be named:
Database Replication 1998-10-13.csv
To disable replication completely, follow these steps:
Step 1 Click System Configuration: CiscoSecure Database Replication.
Step 2 In the Replication Components section, clear all the check boxes.
Step 3 In the Replication Scheduling section, click Manually. This prevents any automated replication from being performed.
Step 4 In the Replication Partners section, if there are any AAA servers listed in the Replication column, click their names and click the left arrow button to move them back into the AAA Servers column.
The RDBMS Synchronization feature simplifies the integration of CiscoSecure ACS with a third-party RDBMS application. RDBMS Synchronization automates the synchronization with other RDBMS data sources and lets you perform the following functions:
The RDBMS Synchronization feature consists of 2 components:
RDBMS Synchronization processes each record in the ODBC Import Table and then deletes the record. Therefore, the ODBC import table can be considered a transaction queue; the data placed in the table is transient. This means that RDBMS Synchronization does not maintain a transaction log/audit trail. If a log is required, the external RDBMS application must create it. Unless the external RDBMS application can recreate the entire transaction history into the ODBC Import Table, we strongly advise that you construct a transaction log file for recovery purposes. You can do this by mirroring all of the transactions in the ODBC Import Table to a second table under the external RDBMS application's control.
If the database is large, it is not practical to recreate the CiscoSecure ACS database by replaying the transaction log for the entire history of the system. Instead, create regular checkpoint backups of the CiscoSecure ACS database and replay the transaction logs from the time of the checkpoint to bring the CiscoSecure ACS's database back up to date (in sync with the external RDBMS application's database). For information on creating a checkpoint backup file, see "Database Backup and Restore Utility" section in "CiscoSecure ACS Command-Line Database Utility."
Replaying transaction logs that slightly predate the checkpoint will not damage the CiscoSecure ACS database, although some transactions might be invalid and reported as errors. As long as the entire transaction log is replayed, the CiscoSecure ACS database will be consistent with the external RDBMS application's database.
The user interface window provided in CSAdmin for configuring RDBMS Synchronization provides control of the following items:
RDBMS Synchronization provides control of the following System DSN parameters:
To configure RDBMS Synchronization to use a particular DSN, click the desired system DSN in the pull-down list of available DSNs and enter the appropriate username and password into the fields provided.
RDBMS Synchronization takes its data from a valid ODBC data source. To display in the CiscoSecure ACS user interface, the data source must first be correctly installed from the Windows NT ODBC Control Panel applet. A Microsoft Access database file (CiscoSecure Transactions.mdb) is supplied with CiscoSecure ACS for use by RDBMS Synchronization. During installation, this ODBC data source is added to the available System DSNs with the name "CiscoSecure DBSync." Using this data source requires no additional ODBC data source configuration because it is installed as the default System DSN for RDBMS Synchronization. By default, the username and password parameters are set to null. For increased data security, the defaults should be changed after installation.
To use a different file or database, such as Microsoft SQL Server or Oracle, you must define a System DSN for this data source that RDBMS Synchronization can use. CiscoSecure ACS provides SQL scripts to help you generate a table in the correct format for both Microsoft SQL Server and Oracle's Oracle8 RDBMS servers.
You can configure RDBMS Synchronization for one of the following schedules:
To select the desired mode of operation, click the appropriate radio button and configure the parameters as appropriate.
By default, RDBMS Synchronization is disabled. To configure Synchronization, click System Configuration: RDBMS Synchronization. If this feature is not displayed, click Interface Configuration: Advanced Options and check the RDBMS Synchronization check box.
RDBMS Synchronization allows you to select one or more target CiscoSecure ACS systems. To select a target system for synchronization, click the desired target system in the left list box and press the right arrow button to move the selection into the right list box of configured target systems. Repeat this process as required.
To deselect a synchronization target, reverse the above procedure using the left arrow button.
Because RDBMS Synchronization is a critical process, CSDB Sync provides visual alerts and logging to notify the system administrator of any problems that occurred during a synchronization event.
If you have an existing ODBC-compliant database, such as Microsoft Access or Oracle, you can import it to a CiscoSecure ACS database. Follow the instructions in this section.
Importing user/group information into one or more ACS servers uses a single table. The CSAccupdate service processes the table and updates local and remote ACS installations as configured.
Because the structure is "flat," not all the fields in the table are required for every type of transaction. The tables in the following sections specify which fields must be present for each transaction type or action.
The following fields are required:
Therefore, these fields are not included when discussing per-action mandatory fields.
Any modification to the database format or the value set that can be assigned to a user or group must be made with reference to this section; otherwise, third-party account information systems might set incorrect user information.
CSAccupdate opens an ODBC system DSN called "CiscoSecureImport." This DSN contains a table named "accountActions." The Update table has the fields listed in Table 7-1. The database that contains the table can be from any vendor, provided that the ODBC drivers can be used with multithreaded services.
| Mnemonic | Field Name | Type | Size | Comments |
|---|---|---|---|---|
CN | ComputerNames | String | 32 | RESERVED by CSAccupdate. |
S | Status | Number | 32 | TRI-STATE:0=not processed, 1=done, 2=failed. This should normally be set to 0. |
UN | UserName | String | 32 | The name of the user to which the transaction applies. |
GN | GroupName | String | 32 | The name of a group to which the transaction applies. |
AI | AppId | String | 255 | The type of configuration parameter to change. |
A | Action | Number | 0-2^16 | The Action required. (See the "Action Codes" section.) |
VN | ValueName | String | 255 | The name of the parameter to change. |
V1 | Value1 | String | 255 | The new value (for numeric parameters, this is a decimal string). |
V2 | Value2 | String | 255 | The name of a TACACS+ protocol; for example, "ip" or RADIUS VSA Vendor ID. |
V3 | Value3 | String | 255 | The name of a TACACS+ service; for example, "ppp" or the RADIUS VSA attribute number. |
DT | DateTime | DateTime |
| The date/time the Action was created. |
SI | SequenceId | AutoNumber | 32 | The unique action ID. |
MN | MessgeNo | Int |
| Used to number related transactions for audit purposes. |
P | Priority | Int |
| The priority with which this update is to be treated. 0 is the lowest priority. |
Records are read from the table in ascending order by Sequence ID and priority. Most systems writing to this table will do so in batch mode, with priority equal to 0. This allows a STAT user addition to occur ahead of the queue if an online user addition is required. When changing transaction priorities, be careful that they are processed in the correct order; for example, the user must be created before the user's password is created.
You can use the MessageNo field to stall related transactions; for example, the addition of a user and subsequent actions to set password values and status. This field is used primarily for third-party billing systems to facilitate an audit trail.
Table 7-2 lists the valid action codes. The Required column indicates which fields should be completed via the field Mnemonic name, except for the mandatory fields, which are assumed. If an action can be applied to either a user or group, "UN|GN" is listed. To make the action affect only the user, leave the group name empty, and vice versa.
| # | Name | Required | Description |
|---|---|---|---|
1 | SET_VALUE | UN|GN, AI, VN, V1, V2 | Sets a value (V1) named (VN) of type (V2) for app (AI). App IDs (AI) can be one of the following:
Value types (V2) can be one of the following:
For example: UN="fred," AI="APP_CSAUTH," VN="My Value"V2="TYPE_MULTI_STRING," V1="str1<tab>str2<tab>str3" |
2 | DELETE_VALUE | UN|GN, AI, VN | Delete value (VN) for app (AI) and user (UN). |
| Specific Actions Related to Creation/Modification of User Accounts | |||
100 | ADD_USER | UN, V1 | Create a new user (32 characters maximum). V1 is used as the initial password. |
101 | DELETE_USER | UN | Remove a user. |
102 | SET_PAP_PASS | UN, V1 | Set the PAP password for a user (64 characters maximum). CHAP/ARAP will also default to this. |
103 | SET_CHAP_PASS | UN, V1 | Set the CHAP/ARAP password for a user. (64 characters maximum). |
104 | SET_OUTBOUND_CHAP_PASS | UN, V1 | Sets the CHAP/ARAP password for a user. (32 characters maximum) |
105 | SET_T+_ENABLE_PASS | UN, V1, V2 | Sets the TACACS+ enable password (V1) (32 characters maximum) and Max Privilege level (V2) (0-15). |
106 | SET_GROUP | UN, GN | Assign the user to a group. |
108 | SET_PASS_TYPE | V1 | Set the password type of the user. This can be one of the internal CSDB password types or any of the external databases supported:
|
109 | REMOVE_PASS_STATUS | UN,V1 | Remove a password status flag. This results in the status states being linked in a logical XOR condition by the CSAuth server. V1 should contain one of the following:
|
110 | ADD_PASS_STATUS | UN, V1 | Defines how password should be expired by CiscoSecure ACS. To set multiple password states for a user, use multiple instances of this action. This results in the status states being linked in a logical XOR condition by the CSAuth server. V1 should contain one of the following:
|
111 | NOT USED |
|
|
112 | SET_PASS_EXPIRY_WRONG | UN,V1 | Set the maximum number of bad authentications allowed (automatic reset on good password if not exceeded) and reset current count. |
113 | SET_PASS_EXPIRY_DATE | UN,V1 | Set the date on which the account expires. The date format should be YYYYMMDD. |
114 | SET_MAX_SESSIONS | UN|GN,V1 | Set the maximum number of simultaneous sessions for a user or group. V1 should contain one of the following values:
|
115 | SET_MAX_SESSIONS_GROUP_USER | GN,V1 | Set the max sessions for a user of the group to one of the following values:
|
| NAS access filters control Telnet access to a NAS; dial access filters control access by dial-up users | |||
120 | INIT_NAS_ACCESS_CONTROL | UN|GN,V1 | Clear the NAS access filter list and initialize permit/deny for any forthcoming filters. V1 should be one of the following values:
|
121 | INIT_DIAL_ACCESS_CONTROL | UN|GN,V1 | Clear the dial-up access filter list and initialize permit/deny for any forthcoming filters. V1 should be one of the following values:
|
122 | ADD_NAS_ACCESS_FILTER | UN|GN,V1 | Add a NAS filter for the user|group. V1 should contain a single (NAS name, NAS port, remote address, CLID) tuple; for example: NAS01,tty0,0898-69696969 Optionally the NAS name can be "All Nases" to specify that the filter applies to all configured NASes and an asterisk (*) to represent all ports. |
123 | ADD_DIAL_ACCESS_FILTER | UN|GN, V1, V2 | Add a dial-up filter for the user|group. V1 should contain one of the following values:
01732-875374,0898-69696969
10.45.6.123,tty0 V2 should contain the filter type as one of the following values:
|
130 | SET_TOKEN_CACHE_SESSION | GN, V1 | Enable/disable token caching for an entire session; V1 is 0=disable, 1=enable. |
131 | SET_TOKEN_CACHE_TIME | GN, V1 | Set the duration that tokens are cached. V1 is the token cache duration in seconds. |
140 | SET_TODDOW_ACCESS | UN|GN, V1 | Set periods during which access is permitted. V1 contains a string of 168 characters. Each character represents a single hour of the week. A `1' represents an hour that is permitted, while a `0' represents an hour that is denied. If this parameter is not specified for a user, the group setting will apply. The default group setting is "permit all." |
150 | SET_STATIC_IP | UN, V1, V2 | Configure the (TACACS+ and RADIUS) IP address assignment for this user . V1 holds the IP address in the following format: xxx.xxx.xxx.xxx V2 should be one of the following:
|
151 | SET_CALLBACK_NO | UN|GN, V1 | Set the callback number for this user or group (TACACS+ and RADIUS). V1 should be one of the following:
|
| TACACS+ and RADIUS Group Settings (and user-level overrides) | |||
161 | DEL_RADIUS_ATTR | UN|GN, VN, Optionally V2, V3 | Deletes the named RADIUS attribute for the group or user where:
|
163 | ADD_RADIUS_ ATTR | UN|GN, VN, V1, Optionally V2, V3 | Add the numbered attribute (VN) to value (V) for the user/group (UN|GN); for example: GN="Group 1," VN="Reply Message," V1="Greetings," UN="fred," VN="Framed-IP-Address," V1="10.1.1.1" Where VN="Vendor-Specific", the Vendor-Specific (VSA) attribute. The fields V2 and V3 should contain the IETF vendor ID and the VSA attribute ID, respectively; for example: V2="9" (Cisco Systems, Inc.) V3="1" (Cisco AV-pair) V1="addr-pool=pool1" (the normal attribute data) RADIUS attribute values can be one of the following:
|
170 | ADD_TACACS_SERVICE | UN|GN, VN, V1, V3, Optionally V2 | Permits the service for that user or group of users. GN="Group 1," V1="ppp," V2="ip" UN="fred," V1="ppp," V2="ip" UN="fred," V1=exec |
171 | REMOVE_TACACS_SERVICE | UN|GN, V1 Optionally V2 | Denies the service for that user or group of users. GN="Group 1," V1="ppp," V2="ip" UN="fred," V1="ppp," V2="ip" UN="fred," V1=exec This also resets the valid attributes for the service. |
172 | ADD_TACACS_ATTR | UN|GN, VN, V1, V3 Optionally V2 | Sets a service specific attribute. The service must already have been permitted either via the HTML interface or using Action 170. GN="Group 1," V1="ppp," V2="ip" VN="routing," V3="true" UN="fred," V1="ppp," V2="ip" VN="route," V3=10.2.2.2 |
173 | REMOVE_TACACS_ATTR | UN|GN, VN, V1 Optionally V2 | Removes a service-specific attribute. GN="Group 1," V1="ppp," V2="ip," VN="routing" UN="fred," V1="ppp," V2="ip," VN="route" |
174 | ADD_IOS_COMMAND | UN|GN, VN, V1 | Authorizes the given Cisco IOS command and determines if any arguments given to the command are to be found in a defined set or are not to be found in a defined set. The defined set is created using Actions 176 and 177. GN="Group 1," VN="telnet," V1="permit" UN="fred," VN="configure," V1="deny" The first example allows the Telnet command to be authorized for users of Group 1. Any arguments can be supplied to the Telnet command as long as they are not matched against any defined via Action 176. The second example allows the configure command to be authorized for user fred, but only if the arguments supplied are permitted by the filter defined by a series of Action 176es. |
175 | REMOVE_IOS_COMMAND | UN|GN, VN | Removes command authorization for the user or group GN="Group 1," VN="telnet" UN="fred," VN="configure" Users of Group 1 can no longer use the Cisco IOS telnet command. User fred can no longer use the configure command. |
176 | ADD_IOS_COMMAND_ARG | UN|GN, VN, V1, V2 | Specifies a set of command-line arguments that are either permitted or denied for the Cisco IOS command contained in VN. The command must have already been added via Action 174. GN="Group 1," VN="telnet," V1="permit," V2="10.1.1.2" UN="fred," VN="show," V1="deny," V2="run" The first example will allow the telnet command with argument 10.1.1.2 to be used by any user in Group 1. The second example ensures that user fred cannot issue the Cisco IOS command show run. |
177 | REMOVE_IOS_COMMAND_ARG | UN|GN, VN, V2 | Remove the permit or deny entry for the given Cisco IOS command argument. GN="Group 1," VN="telnet," V2="10.1.1.1" UN="fred," VN="show," V2="run" |
178 | SET_PERMIT_DENY_ | UN|GN, V1 | The default is that any Cisco IOS commands not defined via a combination of Actions 174 and 175 will be denied. This behavior can be changed so that Cisco IOS commands issued that do not match any of the command/command argument pairs are authorized. GN="Group 1," V1="permit" UN="fred," V1="deny" The first example will allow any command not defined by Action 174. |
179 | REMOVE_ALL_IOS_ | UN|GN | This action removes all Cisco IOS commands defined for a particular user or group. |
210 | RENAME_GROUP | GN,V1 | Renames an existing group to the name supplied in value 1. |
211 | RESET_GROUP | GN | Resets a group back to the factory default. |
212 | SET_VOIP | GN, V1 | Set a Voice over IP (VoIP) group name GN = name of group V1 = ENABLE or DISABLE |
Despite the many actions available, adding a user requires only one transaction: ADD_USER. All other user attributes can safely be left with their default values. Table 7-3 describes the attributes available for both users and groups, as well as type and limits, where applicable. The term NULL is not simply an empty string, but means not set, that is, the value will not be processed. Some features are processed only if they have a value assigned to them.
| Attribute | Logical Type | Limits | Default | Actions |
|---|---|---|---|---|
Username | String | 1-64 characters | N/A | 100, 101 |
ASCII/PAP Password | String | 4-32 characters | Random string | 100, 102 |
CHAP Password | String | 4-32 characters | Random string | 103 |
Outbound CHAP Password | String | 4-32 characters | NULL | 104 |
TACACS+ Enable Password | String Password | 4-32 characters | NULL | 105 |
Integer privilege level | 0-15 characters | NULL | ||
Group | String | 0-100 characters | "Default Group" | 106 |
Password Supplier | Enum | See Table 7-2. | LIBRARY_CSDB | 107 |
Password Type | Enum | See Table 7-2. | PASS_TYPE_CSCB (password is cleartext PAP) | 108 |
Password Expiry Status | Bitwise Enum | See Table 7-2. | PASS_STATUS_ | 109, 110 |
Expiry Data | Short wrong max/current | 0-32,767 | N/A | 112, 113 |
expiry date | N/A | N/A | ||
Max Sessions | Unsigned short | 0-65535 | MAX_SESSIONS_AS_GROUP | 114 |
TODDOW Restrictions | String | 168 characters | Permit All | 140 |
NAS Access Control | Bool enabled | T/F | NULL | 120, 122 |
Bool permit/deny | T/F | |||
ACL String (See Table 7-2.) | 0-31 KB | |||
Dial-Up Access Control | Bool enabled | T/F | NULL | 121, 123 |
Bool permit/deny | T/F | NULL | ||
ACL String (See Table 7-2.) | 0-31 KB | NULL | ||
Static IP Address | Enum scheme | (See Table 7-2.) | client | 150 |
String IP/Pool name | 0-31 KB | NULL | ||
Callback Number | String | 0-31 KB | NULL | 151 |
TACACS Attributes | Formatted String | 0-31 KB | NULL | 160, 162 |
RADIUS Attributes | Formatted String | 0-31 KB | NULL | 170, 173 |
UDF 1 | String Real Name | 0-31 KB | NULL | 1, 2 |
UDF 2 | String Description | 0-31 KB | NULL | 1, 2 |
UDF3 | String | 0-31 KB | NULL | 1, 2 |
|
|