In this section:
Overview
The SBC includes several default groups (such as Administrator, Operator, Field Service, Guest, Calea and Security Auditor) that use various levels of access to CDB data, and to CLI and NETCONF commands. Group permissions are based on the defined AAA rules which are not user-editable. As a result, there is little flexibility to create user-defined groups with permissions for the pre-defined groups. Additionally, the users belonging to the custom group can only login to the CLI, but not the EMA.
Starting with Release 8.1, the SBC is enhanced to create user-defined groups with flexibility to modify the AAA rules. New functionality includes:
- Providing custom group users access to both the CLI and EMA.
- Flexibility to modify the AAA rules to the newly created custom group.
Configuration Example
To overcome adding one rule at a time for a new group, the CLI command aaarule-display-generatecl
i is added to display the applicable rules for an existing group and get an equivalent output in a file containing CLI commands. The user then edits this file to define the new set of rules and source the updated file in CLI to assign rules to the new custom group.
aaarule-display-generatecli
Command Syntax
To create new rules, refer to Local Authentication - CLI
Create the new rules for the custom group by executing the command:
aaarule-display-generatecli -h usage: [--help|-h] [--administrator|-a] [--operator|-o] [--fieldService|-f] [--guest|-g] [--calea|-c] [--securityAuditor|-s] [--group <new group name>] --display|-cli --help|-h: Help for usage --administrator|-a: Prints Administrator rules --operator|-o: Prints Operator rules --fieldService|-f: Prints Field Service rules --guest|-g: Prints Guest rules --calea|-c: Prints Calea rules --securityAuditor|-s: Prints Security Auditor rules --cli: CLI output for any of the specified groups. At least one group must be given in argument. --display: Display rules for any of the specified groups. At least one group must be given in argument. --group: New group name. The rules will be applied to this group. Else the name will be derived from default group
The options allow you to display and/or create CLI output files for one or more groups at a time. The user group name is required and/or display (--display) or a cli (--cli) option as mandatory parameters.
If the –cli option is given, the SBC stores the CLI output in the user home directory and can modify it.
Assigning New Rules to Custom Group
To assign the new rules for the custom group, perform the following:
- Use tool to view the rules for existing groups.
- Create a group similar to the existing groups, and use the tool to fetch the rules of an existing group in the CLI file.
- FTP the CLI file and update it with the new rules.
- Update to change the privileges of the desired custom group.
Create a custom group by executing the command:
set oam localAuth group <custom-group>
If the custom group name is not given as a command option, update the CLI file with the same group name as created in above step.
- FTP the CLI file back to SBC in the same location.
Source the cli file by executing the command
Source <cli file name>
Examples for Creating Custom Groups and Assigning the Rules
Creating New Custom group for Administrator
For example, to create an Administrator-like group without modify permissions for the data under the following:
user
rule-list
To create pseudo-administrator custom group, perform the following:
Create a cli file with the Administrator rules. A new file Administrator-cli.txt is created.
aaarule-display-generatecli--administrator --cli --group PseudoAdmin
- Transfer the file from the SBC, using the SFTP from the CLI user's home account.
Assign restrictions by executing the command:
set oam localAuth rule-list DATA-PseudoAdmin-0 group PseudoAdmin rule 0 module-name * path /oam/localAuth/user context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-PseudoAdmin-1 group PseudoAdmin rule 1 module-name * path /oam/localAuth/rule-list context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-PseudoAdmin-2 group PseudoAdmin rule 2 module-name * path * context * access-operations read,create,update,delete,exec action permit commit set oam localAuth rule-list CMD-PseudoAdmin-0 group PseudoAdmin cmdrule 0 command "*" context cli access-operations read,exec action permit set oam localAuth rule-list CMD-PseudoAdmin-1 group PseudoAdmin cmdrule 1 command "*" context netconf access-operations read,exec action permit commit
- Create a custom group by executing the command:
set oam localAuth group PseudoAdmin
- Transfer the file using SFTP back to the SBC.
Source the file by executing the command:
source Administrator-cli.txt
NoteCreating a custom administrator group is allowed; however, it will have limited capabilities due to the restrictions in the code
The following table highlights the differences in permissions between the Administrator and Customer Administrator.
Creating New Custom group for Debugging
Create a new group similar to Guest group but with the permissions for only
softReset
andswitchovers
commands.
The following will create a new CLI fileGuest-cli.txt
containing rules for Guest group.aaarule-display-generatecli --Guest --cli --group NewGuest
- Transfer the file from the SBC, using the SFTP from the CLI user's home account.
Update the rule list as follows:
set oam localAuth rule-list DATA-Guest-13 group NewGuest rule 13 module-name * path /addressContext context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-14 group NewGuest rule 14 module-name * path /alarms context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-15 group NewGuest rule 15 module-name * path /global context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-16 group NewGuest rule 16 module-name * path /profiles context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1 module-name * path /system/admin/switchover context * access-operations create,update,delete,exec action permit set oam localAuth rule-list DATA-Guest-16_2 group NewGuest rule 16_2 module-name * path /system/admin/softReset context * access-operations create,update,delete,exec action permit set oam localAuth rule-list DATA-Guest-17 group NewGuest rule 17 module-name * path /system context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-18 group NewGuest rule 18 module-name * path /oam context * access-operations create,update,delete,exec action deny
Here two new rules; 16_1 and 16_2 are added before rule 17, which enables the
softReset
andswitchovers.
Create a custom group by executing the command:
set oam localAuth group NewGuest
Transfer the file using SFTP back to the SBC.
Source the cli file by executing the command
Source Guest-cli.txt
Order of Rule Creation for Custom Group
The SBC matches rules in the order the rules are defined on the SBC. The SBC traverses the rule list until it finds a match. Once the SBC finds a match, it returns the result and ignores further rules in the list. Thus, if the order is not correctly defined, it is possible for a rule to be never found in a match.
Correct | Incorrect |
---|---|
Rules to restrict access for all the systems but allow the switchover and softReset permissions. | |
set oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1 module-name * path /system/admin/switchover context * access-operations create,update,delete,exec action permit |
Note: This is incorrect because the generic/system matches before the more specific entries for /system/admin. set oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1 module-name * path /system/admin/switchover context * access-operations create,update,delete,exec action permit |
Rule for all the systems but deny the switchover and softReset permissions | |
set oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1 module-name * path /system/admin/switchover context * access-operations create,update,delete,exec action deny |
Note: This is incorrect because the generic /system matches before the more specific /system/admin entries set
oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1
module-name * path /system/admin/switchover context * access-operations
create,update,delete,exec action deny set oam localAuth
rule-list DATA-Guest-16_2 group NewGuest rule 16_2 module-name * path
/system/admin/softReset context * access-operations
create,update,delete,exec action deny |
Redundant Rules
The following commands are two separate examples of the redundant commands. The SBC does not need specific permit rules when it has a generic rule to permit all the operations. The SBC does not need specific deny rules when it has generic rule to deny all operations.
Example 1:
set oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1 module-name * path /system/admin/switchover context * access-operations create,update,delete,exec action permit set oam localAuth rule-list DATA-Guest-16_2 group NewGuest rule 16_2 module-name * path /system/admin/softReset context * access-operations create,update,delete,exec action permit set oam localAuth rule-list DATA-Guest-17 group NewGuest rule 17 module-name * path /system context * access-operations create,update,delete,exec action permit
Example 2:
set oam localAuth rule-list DATA-Guest-16_1 group NewGuest rule 16_1 module-name * path /system/admin/switchover context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-16_2 group NewGuest rule 16_2 module-name * path /system/admin/softReset context * access-operations create,update,delete,exec action deny set oam localAuth rule-list DATA-Guest-17 group NewGuest rule 17 module-name * path /system context * access-operations create,update,delete,exec action deny
Difference between CLI and EMA paths
EMA uses different data paths compared to CLI in the CDB data model. Hence, while defining the rule, check the path and accordingly apply in the CLI or the EMA.
The following table lists the path differences between CLI and EMA.
For example,
CLI | EMA |
---|---|
Rule to deny changes to rule-list | |
set oam localAuth rule-list DATA-Administrator-1 group NewAdministrator rule 1 module-name * path /oam/localAuth/rule-list context * access-operations create,update,delete,exec action deny | set oam localAuth rule-list DATA-Administrator-2 group NewAdministrator rule 2 module-name * path /AAA/rule-list context * access-operations create,update,delete,exec action deny |
Rule to Restrict Audit log | |
set oam localAuth rule-list DATA-Administrator-1 group NewAdministrator rule 1 module-name * path oam/eventLog/typeAdmin[type=audit] context * access-operations create,update,delete,exec action deny | set oam localAuth rule-list DATA-Administrator-1 group NewAdministrator rule 1 module-name * path /eventLog/typeAdmin[type=audit] context * access-operations create,update,delete,exec action deny |
Rule to Restrict eventLogValidation | |
set oam localAuth rule-list DATA-Administrator-1 group NewAdministrator rule 1 module-name * path /security/oam//eventLogValidation context * access-operations create,update,delete,exec action deny | set oam localAuth rule-list DATA-Administrator-1 group NewAdministrator rule 1 module-name * path /security/eventLogValidation context * access-operations create,update,delete,exec action deny |
Configuration Examples
Custom groups are used to associate a set of rules in a specific order to a set of users.
The steps to create and configure the custom group with the rules and granting permission include:
- Viewing the existing group with the permissions
- Using the existing group to Create Custom Group
- Updating the Rules
- Applying the permission
- Sourcing the file
Viewing the existing group with the permissions
View the existing rules for the administrator by executing the command:
aaarule-display-generatecli --administrator --display
The following output displays the existing rules for an Administrator group.
Group Path Permission Context Action ===== ==== ========== ======= ====== * /AAA/users/changePassword read exec * permit * /oam/localAuth/users read create update delete exec cli deny * /AAA/users read create update delete exec netconf deny * /system/serverAdmin/hwType create update delete exec * deny * /oam/localAuth/users/changePassword read exec * permit * /oam/localAuth/userStatus/setRsaKey read create update delete exec * permit * /oam/localAuth/userStatus/deleteRsaKey read create update delete exec * permit * /oam/localAuth/userStatus/showRsaKey read create update delete exec * permit * /oam/aaa read create update delete exec netconf deny * /oam/nacm read create update delete exec netconf deny * /oam/localAuth/user create update delete exec rest deny * /oam/traps/admin/* read create update delete exec * permit * /oam/traps/admin create update delete * deny * /system/fileStatisticsAdmin/ create delete * deny * /profiles/dtmfTrigger/ delete * deny * /addressContext/intercept read create update delete exec * deny Administrator * read create update delete exec * permit * change-password read exec * permit * request alarms current comment alarmList * cli deny * request alarms current state alarmList * cli deny * request alarms clear alarmList * cli deny Administrator * read exec cli permit Administrator * read exec netconf permit
Using the Existing Group to Create Custom Group
Create the new custom group from the existing group administrator by executing the command:
aaarule-display-generatecli --administrator --cli --group PseudoAdmin
This command creates the CLI file for a Pseudo-admin group. The rules are derived from an Administrator group and the command updates the rules and applies the permission.
Sourcing the Files
Source the file by executing the command:
admin@SBXUK23-1> source Administrator-cli.txt