ODBC import definitions are a listing of the action codes allowable in an accountActions table. The RDBMS Synchronization feature of Cisco Secure Access Control Server for Windows NT/2000 Servers Version 3.0 (Cisco Secure ACS) uses a table named "accountActions" as input for automated or manual updates of the CiscoSecure user database. For more information about the RDBMS Synchronization feature and the accountActions table, see the "RDBMS Synchronization" section.
The third-party system that writes to the accountActions table must adhere to the accountActions table specification and must only use the action codes detailed in the "Action Codes" section. Otherwise, RDBMS Synchronization may import incorrect information into the CiscoSecure user database or may fail to occur at all.
accountActions Table Format
Each row in an accountActions table has 14 fields (or columns). Table G-1 lists the fields that compose an accountActions table in the order in which they appear in the table.
The one-letter or two-letter abbreviations given in the Mnemonic column are a shorthand notation used to indicate required fields for each action code in the "Action Codes" section.
The new value (for numeric parameters, this is a decimal string).
Value2
V2
String
255
The name of a TACACS+ protocol; for example, "ip" or RADIUS VSA Vendor ID.
Value3
V3
String
255
The name of a TACACS+ service; for example, "ppp" or the RADIUS VSA attribute number.
DateTime
DT
DateTime
—
The date/time the Action was created.
MessageNo
MN
Int
—
Used to number related transactions for audit purposes.
ComputerNames
CN
String
32
RESERVED by CSDBSync.
AppId
AI
String
255
The type of configuration parameter to change.
Status
S
Number
32
TRI-STATE:0=not processed, 1=done, 2=failed. This should normally be set to 0.
accountActions Table Mandatory Fields
Three fields in the accountActions 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 three fields are required for all transaction types:
Action
DateTime
SequenceID
In addition to the three required fields above, the UserName and GroupName fields are required for many actions:
If a transaction is acting upon a user account, a value is required in the UserName field.
If a transaction is acting upon a group, a value is required in the GroupName field.
If a transaction is acting upon AAA client configuration, neither the UserName field nor the GroupName field is required.
Note The UserName and GroupName fields are mutually exclusive; only one of these two fields can have a value and neither field is always required.
accountActions Table Processing Order
Cisco Secure ACS reads rows from the accountActions table and processes them in a specific order. Cisco Secure ACS determines the order first by the values in the Priority fields (mnemonic: P) and then by the values in the Sequence ID fields (mnemonic: SI). Cisco Secure ACS processes the rows with the highest priority first. If rows have an equal priority, Cisco Secure ACS processes them by their sequence ID, with the lowest sequence ID processed first. For example, if the priority for row A is higher than the priority for row B, Cisco Secure ACS would process row A first, regardless of whether row B has a lower sequence ID or not.
Thus, the Priority field (P) enables transactions of higher importance to occur first, such as deleting a user or changing a password. In the most common implementations of RDBMS Synchronization, the third-party system writes to the accountActions table in batch mode, with all actions (rows) assigned a priority of zero (0).
Note When changing transaction priorities, be careful that they are processed in the correct order; for example, a user account must be created before the user password is assigned.
You can use the MessageNo field (mnemonic: MN) to associate related transactions, such as the addition of a user and subsequent actions to set password values and status. You can use the MessageNo field to create an audit trail for the third-party system that writes to the accountActions table.
Action Codes
This section provides the action codes valid for use in the Action field (mnemonic: A) of your accountActions table. The Required column uses the field mnemonic names to indicate which fields should be completed, except for the mandatory fields, which are assumed. For more information about the mnemonic names of accountActions table fields, see Table G-1. For more information about the mandatory fields, see the "accountActions Table Mandatory Fields" section.
If an action can be applied to either a user or group, "UN|GN" appears, using the vertical bar to indicate that either one of the two fields is required. To make the action affect only the user, leave the group name empty, and vice versa.
This section contains the following topics about action codes:
The two most fundamental action codes are SET_VALUE (action code: 1) and DELETE_VALUE (action code: 2), described in Table G-2.
The SET_VALUE (action code: 1) and DELETE_VALUE (action code: 2) actions, described in Table G-2, instruct RDBMS Synchronization to assign a value to various internal attributes in Cisco Secure ACS. Unless asked to use these action codes for other purposes by a Cisco representative, you can only use these action codes for assigning values to user-defined fields (see the "User-Specific Attributes" section).
Table G-2 Action Codes for Setting and Deleting Values
Action
Code
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:
APP_CSAUTH
APP_CSTACACS
APP_CSRADIUS
APP_CSADMIN
Value types (V2) can be one of the following:
TYPE_BYTE—Single 8-bit number.
TYPE_SHORT—Single 16-bit number.
TYPE_INT—Single 32-bit number.
TYPE_STRING—Single string.
TYPE_ENCRYPTED_STRING—Single string to be saved encrypted.
TYPE_MULTI_STRING—Tab-separated set of substrings.
TYPE_MULTI_INT—Tab-separated set of 32-bit numbers.
Action Codes for Creating and Modifying User Accounts
Table G-3 lists the action codes for creating, modifying, and deleting user accounts.
Note Before you can modify a user account, such as assigning a password, you must create the user account, either in the HTML interface or by using the ADD_USER action (action code: 100).
Transactions using these codes affect the configuration displayed in the User Setup section of the HTML interface. For more information about the User Setup section, see "Setting Up and Managing User Accounts."
Table G-3 User Creation and Modification Action Codes
Action
Code
Name
Required
Description
100
ADD_USER
UN, V1
Create a user (32 characters maximum). V1 is used as the initial password. Optionally, the user can also be assigned to a group.
101
DELETE_USER
UN
Remove a user.
102
SET_PAP_PASS
UN, V1
Set the PAP password for a user (64 ASCII 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
Set the user's Cisco Secure ACS group assignment.
108
SET_PASS_TYPE
V1
Set the password type of the user. This can be one of the CiscoSecure user database password types or any of the external databases supported:
PASS_TYPE_RADIUS_TOKEN—External RADIUS token server database password
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:
PASS_STATUS_EXPIRES—Password expires on a given date.
PASS_STATUS_NEVER—Password never expires.
PASS_STATUS_WRONG—Password expires after a given number of attempts.
PASS_STATUS_DISABLED—The account has been disabled.
110
ADD_PASS_STATUS
UN, V1
Defines how a password should be expired by Cisco Secure 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:
PASS_STATUS_EXPIRES—Password expires on a given date.
PASS_STATUS_NEVER—Password never expires.
PASS_STATUS_WRONG—Password expires after a given number of attempts.
PASS_STATUS_RIGHT—Password expires after a given number of attempts.
PASS_STATUS_DISABLED—The account has been disabled.
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:
MAX_SESSIONS_UNLIMITED
MAX_SESSIONS_AS_GROUP
1-65534
115
SET_MAX_
SESSIONS_GROUP_USER
GN,V1
Set the max sessions for a user of the group to one of the following values:
MAX_SESSIONS_UNLIMITED
1-65534
260
SET_QUOTA
GN,VN,V1,V2
Used to set a quota for a user or group.
VN defines the quota type. Valid values are:
online time—The quota limits the user or group by the number of seconds logged in to the network for the period defined in V2.
sessions—The quota limits the user or group by the number of sessions on the network for the period defined in V2.
V1 defines the quota. If VN is set to sessions, V1 is the maximum number of sessions in the period defined in V2. If VN is set to online time, V1 is the maximum number of seconds.
V2 holds the period for the quota. Valid values are:
QUOTA_PERIOD_DAILY—The quota is enforced in 24-hour cycles, from 12:01 A.M. to midnight.
QUOTA_PERIOD_WEEKLY—The quota is enforced in 7-day cycles, from 12:01 A.M. Sunday until midnight Saturday.
QUOTA_PERIOD_MONTHLY—The quota is enforced in monthly cycles, from 12:01 A.M. on the first of the month until midnight on the last day of the month.
QUOTA_PERIOD_ABSOLUTE—The quota is enforced in an ongoing basis, without an end.
261
DISABLE_QUOTA
UN|GN,VN
Disable a group or user usage quota.
VN defines the quota type. Valid values are:
online time—The quota limits the user or group by the number of seconds logged in to the network for the period defined in V2.
sessions—The quota limits the user or group by the number of sessions on the network for the period defined in V2.
262
SET_QUOTA_
APPLY_TYPE
UN,VN
Defines whether a user's usage quota is determined by the user's group quota or by a quota unique to the user. V1 makes this specification. Valid values for V1 are:
ASSIGNMENT_FROM_USER
ASSIGNMENT_FROM_GROUP
263
RESET_COUNTERS
UN|GN
Resets usage quota counters for a user or group.
270
SET_DCS_TYPE
UN|GN,VN,V1, Optionally V2
Set the type of device command set (DCS) authorization for a group or user.
VN defines the service. Valid service types are:
shell—Cisco IOS shell command authorization.
pixshell—Cisco PIX command authorization.
If additional DCS types have been added to your Cisco Secure ACS, you can find the valid value in the Interface Configuration page for TACACS+ (Cisco IOS). The valid values appear in parentheses after the service title, such as PIX Shell (pixshell).
V1 defines the assignment type. The valid values for VN are:
none—Sets no DCS for the user or group.
as group—For users only, this value signifies that the user's DCS settings for the service specified should be the same as the user's group DCS settings.
static—Sets a DCS for the user or group for all devices enabled to perform command authorization for the service specified.
If V1 is set to static, V2 is required and must contain the name of the DCS to assign to the user or group for the given service.
ndg—Specifies that command authorization for the user or group is to be done on a per-NDG basis. Use action 271 to add DCS to NDG mappings for the user or group.
Changing a user or group assignment type (V1) results in clearing previous data, including NDG to DCS mappings (defined by action 271).
271
SET_DCS_NDG_
MAP
UN|GN,VN,V1,V2
When the assignment type specified by a 270 action code is ndg, use this action code to map between the device command set and the NDG.
VN defines the service. Valid service types are:
shell—Cisco IOS shell command authorization.
pixshell—Cisco PIX command authorization.
If additional DCS types have been added to your Cisco Secure ACS, you can find the valid value in the Interface Configuration page for TACACS+ (Cisco IOS). The valid values appear in parentheses after the service title, such as PIX Shell (pixshell).
V1 defines the name of the NDG. Use the name of the NDG as it appears in the HTML interface. For example, if you have configured an NDG named "East Coast NASes" and want to use action 271 to apply a DCS to that NDG, V1 should be "East Coast NASes".
V2 defines the name of the DCS. Use the name of the DCS as it appears in the HTML interface. For example, if you have configured a DCS named "Tier2 PIX Admin DCS" and want to use action 271 to apply it to an NDG, V2 should be "Tier2 PIX Admin DCS".
Action Codes for Initializing and Modifying Access Filters
Table G-4 lists the action codes for initializing and modifying AAA client access filters. AAA client access filters control Telnet access to a AAA client. Dial access filters control access by dial-up users.
Transactions using these codes affect the configuration displayed in the User Setup and Group Setup sections of the HTML interface. For more information about the User Setup section, see "Setting Up and Managing User Accounts." For more information about the Group Setup section, see "Setting Up and Managing User Groups."
Table G-4 Action Codes for Initializing and Modifying Access Filters
Action
Code
Name
Required
Description
120
INIT_NAS_ACCESS_
CONTROL
UN|GN,V1
Clear the AAA client access filter list and initialize permit/deny for any forthcoming filters. V1 should be one of the following values:
ACCESS_PERMIT
ACCESS DENY
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:
ACCESS_PERMIT
ACCESS DENY
122
ADD_NAS_ACCESS_FILTER
UN|GN,V1
Add a AAA client filter for the user|group.
V1 should contain a single (AAA client name, AAA client port, remote address, CLID) tuple; for example:
NAS01,tty0,0898-69696969
Optionally, the AAA client name can be "All AAA clients" to specify that the filter applies to all configured AAA clients 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:
Calling station ID
Called station ID
Calling and called station ID; for example:
01732-875374,0898-69696969
AAA client IP address, AAA client port; for example:
10.45.6.123,tty0
V2 should contain the filter type as one of the following values:
CLID—The user is filtered by the calling station ID.
DNIS—The user is filtered by the called station ID.
CLID/DNIS—The user is filtered by both calling and called station IDs.
AAA client/PORT—The user is filtered by AAA client IP and AAA client port address.
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 applies. The default group setting is "111111111111" and so on.
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:
ALLOC_METHOD_STATIC—The IP address in V1 is assigned to the user in the format "xxx.xxx.xxx.xxx."
ALLOC_METHOD_NAS_POOL—
The IP pool named in V1 (configured on the AAA client) will be assigned to the user.
ALLOC_METHOD_AAA_POOL—
The IP pool named in V1 (configured on the AAA server) will be assigned to the user.
ALLOC_METHOD_CLIENT—The dial-in client will assign its own IP address.
ALLOC_METHOD_AS_GROUP—
The IP address assignment configured for the group will be used.
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:
Callback number—Literally, the phone number the AAA client is to call back.
none—No callback is allowed.
roaming—The dial-up client determines the callback number.
as group—Use the callback string or method defined by the group.
Action Codes for Modifying TACACS+ and RADIUS Group and User Settings
Table G-5 lists the action codes for creating, modifying, and deleting TACACS+ and RADIUS settings for Cisco Secure ACS groups and users. In the event that Cisco Secure ACS has conflicting user and group settings, user settings always override group settings.
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"
or
UN="fred"
VN="configure"
V1="deny"
The first example permits 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 permits 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"
or
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:
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"
or
UN="fred"
VN="show"
V2="run"
178
SET_PERMIT_
DENY_
UNMATCHED_
IOS_
COMMANDS
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 issued Cisco IOS commands that do not match any command/command argument pairs are authorized:
GN="Group 1"
V1="permit"
or
UN="fred"
V1="deny"
The first example will permit any command not defined by Action 174.
179
REMOVE_ALL_
IOS_
COMMANDS
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
Enables or disables Voice over IP (VoIP) support for the group named, as follows:
GN = name of group
V1 = ENABLE or DISABLE
Action Codes for Modifying Network Configuration
Table G-6 lists the action codes for adding AAA clients, AAA servers, and network device groups, in addition to proxy table entries. Transactions using these codes affect the configuration displayed in the Network Configuration section of the HTML interface. For more information about the Network Configuration section, see "Setting Up and Managing Network Configuration."
Table G-6 Action Codes for Modifying Network Configuration
Action
Code
Name
Required
Description
220
ADD_NAS
VN, V1, V2, V3
Add a new AAA client (named in VN) with an IP address (V1), shared secret key (V2), and vendor (V3). Valid vendors are as follows:
For the named AAA client (VN) set one of the per-AAA client flags (V1). Use the action once for each flag required. Valid values for per-AAA client flags are as follows:
FLAG_SINGLE_CONNECT
FLAG_LOG_KEEP_ALIVE
FLAG_LOG_TUNNELS
222
DEL_HOST
VN
Delete the named AAA client (VN).
230
ADD_AAA_
SERVER
VN, V1, V2
Add a new AAA server named (VN) with IP address (V1), shared secret key (V2).
231
SET_AAA_
TYPE
VN, V1
Set the AAA server type for server (VN) to value in V1, which should be one of the following:
TYPE_ACS
TYPE_TACACS
TYPE_RADIUS
The default is AAA_SERVER_TYPE_ACS
232
SET_AAA_
FLAG
VN, V1
For the named AAA server (VN) set one of the per-AAA client flags (V1):
FLAG_LOG_KEEP_ALIVE
FLAG_LOG_TUNNELS
Use the action once for each flag required.
233
SET_AAA_
TRAFFIC_
TYPE
VN, V1
For the named AAA server (VN), set the appropriate traffic type (V1):
TRAFFIC_TYPE_INBOUND
TRAFFIC_TYPE_OUTBOUND
TRAFFIC_TYPE_BOTH
The default is TRAFFIC_TYPE_BOTH.
234
DEL_AAA_
SERVER
VN
Delete the named AAA server (VN).
240
ADD_PROXY
VN, V1, V2, V3
Add a new proxy markup (VN) with markup type (V1) strip markup flag (V2) and accounting flag (V3).
The markup type (V1) must be one of the following:
MARKUP_TYPE_PREFIX
MARKUP_TYPE_SUFFIX
The markup strip flag should be TRUE if the markup is to be removed from the username before forwarding.
The accounting flag (V3) should be one of the following:
ACCT_FLAG_LOCAL
ACCT_FLAG_REMOTE
ACCT_FLAG_BOTH
241
ADD_PROXY_TARGET
VN, V1
Add to named proxy markup (VN) the host name (V1). The host should already be configured on the Cisco Secure ACS.
The order in which proxy targets are added sets the proxy search order; the first target added is the first target proxied to, and so on. The order must be changed through the HTML interface.
242
DEL_PROXY
VN
Delete the named proxy markup (VN).
250
ADD_NDG
VN
Create a network device group (NDG) named (VN).
251
DEL_NDG
VN
Delete the named NDG.
252
ADD_HOST_TO_NDG
VN, V1
Add to the named AAA client/AAA server (VN) the NDG (V1).
300
RESTART_
PROTO_MODULES
—
Restart the CSRadius and CSTacacs services to apply new settings.
Action Code for Deleting the CiscoSecure User Database
Table G-7 lists the action code for deleting all users and groups from the CiscoSecure user database.
Caution Using action code 200 irrevocably deletes all users and groups from the CiscoSecure user database. Before using this action code, we strongly recommend that you backup the CiscoSecure user database.
Table G-7 Action Code for Deleting the CiscoSecure User Database
Action
Code
Name
Required
Description
200
DEL_CSDB
—
Delete all users and groups from the CiscoSecure user database. This code is particularly useful if you intend to rebuild the CiscoSecure user database using RDBMS synchronization.
Cisco Secure ACS Attributes and Action Codes
This section complements the previous section by providing an inverse reference; the following topics contain tables that list Cisco Secure ACS attributes, their data types and limits, and the action codes you can use to act upon the Cisco Secure ACS attributes:
Table G-8 lists the attributes that define a Cisco Secure ACS user, including their data types, limits, and default values. It also provides the action code you can use in your accountActions table to affect each attribute. Although there are many actions available, adding a user requires only one transaction: ADD_USER. You can safely leave other user attributes at their default values. 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. For more information about action codes, see the "Action Codes" section.
User-defined attributes (UDAs) are string values that can contain any data, such as social security number, department name, telephone number, and so on. You can configure Cisco Secure ACS to include UDAs on accounting logs about user activity. For more information about configuring UDAs, see "User Data Configuration Options" section.
RDBMS Synchronization can set UDAs by using the SET_VALUE action (code 1) to create a value called "USER_DEFINED_FIELD_0" or "USER_DEFINED_FIELD_1". For accountActions rows defining a UDA value, the AppId (AI) field must contain "APP_ CSAUTH" and the Value2(V2) field must contain "TYPE_STRING".
Note If more than two UDAs are created, only the first two are passed to accounting logs.
Group-Specific Attributes
Table G-10 lists the attributes that define a Cisco Secure ACS group, including their data types, limits, and default values. It also provides the action code you can use in your accountActions table to affect each field. For more information about action codes, see the "Action Codes" section.
Table G-11 presents an example of an accountActions table that contains some of the action codes described in Action Codes. First user "fred" is created, along with his passwords, including a TACACS_ Enable password with privilege level 10. Fred is assigned to "Group 2." His account expires after December 31, 1999, or after 10 incorrect authentication attempts. Attributes for Group 2 include Time-of-Day/Day-of-Week restrictions, token caching, and some RADIUS attributes.
Note This example omits several columns that should appear in any accountActions table. The omitted columns are Sequence ID (SI), Priority (P), DateTime (DT), and MessageNo (MN).
