Administrator Accounts

This chapter describes how to configure and modify administrator accounts for management access to ACOS and provides the following information:

     Additional Administrator Accounts

     Administrator Lockouts

     Role-Based Access Control

Additional Administrator Accounts

This section contains the following topics:

     Default Administrator Account

     Configuring an Administrator Account by Using the GUI

     Configuring an Administrator Account by Using the CLI

     Deleting an Administrator Account

     Recovering an Administrator Password

Default Administrator Account

By default, the ACOS device has one administrator account called admin. This account has global read/write privileges and can configure additional administrator accounts with the following settings:

     A username and password

     An IP host or subnet address from which the administrator can log in

     A user interface that the administrator can use (CLI, GUI, or aXAPI)

     An L3V partition, if applicable

     An account state (enabled or disabled)

NOTE:                               If you are configuring an administrator account for an L3V partition, see “Configuring Partition Admin Accounts” in the Configuring Application Delivery Partitions guide.

Configuring an Administrator Account by Using the GUI

To configure an administrator account for “exampleadmin” who will have global read and write privileges:

1.     Hover over System in the menu bar, then select Admin from the drop-down menu.

2.     On the Users tab, click Create.

3.     Enter “exampleadmin” in the Username field.

4.     Enter a password for the new administrator account.

5.     Verify that Enable is selected in the Enable field (selected by default).

6.     In the Access section, verify that all three user interfaces are selected (they should be selected by default).

7.     In the Privilege type field, select Global.

8.     In the Privilege field, select Read/Write from the drop-down list.

gui_create_admin.PNG

9.     Click Create.

10.  Return to the Admin table and verify that the new administrator appears in the list.

Configuring an Administrator Account by Using the CLI

To configure an administrator account:

1.     To specify an admin username and password, enter the following commands:

ACOS(config)# admin admin1 password admin_a10

 

2.     To enable or disable access to a user interface, enter one of the following commands:

     To enable access to a user interface (for example, GUI access), enter the following command:

ACOS(config-admin:admin1)# access web

     To disable access to a user interface (for example, CLI) enter the following command:

ACOS(config-admin:admin1)# no access cli

 

3.     To set user privileges, enter the following commands:

ACOS(config-admin:admin1)# privilege read

ACOS(config-admin:admin1)# privilege write

 

4.     To set up a trusted host IP, enter the trusted-host command:

ACOS(config-admin:admin1)# trusted-host 255.255.255.255 /24

 

5.     To activate the user, enter the following command:

ACOS(config-admin:admin1)# enable

Modify Admin User successful!

 

Deleting an Administrator Account

An administrator with root privileges can delete other administrator accounts.

Before you delete an administrator account, complete the following tasks:

     Determine whether the administrator has active sessions.

     Clear any sessions the administrator has open.

To delete an admin account, you first must terminate any active sessions the administrator account has open. The account is not deleted if open sessions exist.

Deleting an Administrator Account Using the GUI

To delete an administrator account:

1.     Click System > Admin.

2.     Select the checkbox next to the administrator name that you want to delete.

3.     Click Delete.

Deleting an Administrator Account Using the CLI

To delete an admin account:

1.     To display the administrator session table, enter the following command:

show admin session

 

2.     To clear an administrator session, enter the following command:

clear admin session session-id

 

The session-id is listed in the ID column of the show admin session output.

3.     To delete the administrator account, enter the following command at the global configuration level:

no admin admin-username

Recovering an Administrator Password

This section describes how to recover in the event your admin password is lost.

This procedure can only be performed through the security console, and only within the first five minutes of rebooting the ACOS device.

1.     Use the show version or show hardware commands and record the serial number for your device.

2.     Reboot the ACOS device.

3.     Connect to the serial console.

4.     When prompted for the user name and password, enter the following:

User Name: reset

Password: serial number for your device

Use the serial number recorded in step 1, or locate the serial number on the rear of your ACOS device.

5.     After logging in, the CLI presents the following questions:

a.     Do you want to reset admin password to default?[y/n]:

Answering y to this question resets the admin user name and password to the factory default admin and a10.

b.     Do you want to reset enable password to default?[y/n]:

Answering y to this question resets the enable password to the factory default, which is no password.

c.     Do you want to erase startup config?[y/n]:

Answering y to this question clears the startup config, thus returning the device to its factory default settings.

CAUTION:                     Answering y to this questions means you must reconfigure the device.

6.     Answer y to the first question so that you can log on to the device; answer the other two questions as desired for your needs.

7.     After you log on to the device, change the admin password for security purposes.

Administrator Lockouts

By default, there is no limit to the number of times you can enter an incorrect password with an administrator account to log in. You can enable the ACOS device to lock administrator accounts for a period after a specific number of invalid passwords have been entered.

This section contains the following information:

     Lockout Parameters

     Configuring Administrator Lockout Using the GUI

     Configuring Administrator Lockout Using the CLI

Lockout Parameters

TABLE 1    lists the administrator lockout parameters that you can configure.

TABLE 1       Admin Lockout Parameters

Parameter

Description

Default

Feature state

Controls whether admin accounts can be locked.

Disabled

Threshold

Number of failed login attempts allowed for an admin account before it is locked.

5

Reset time

Number of minutes the ACOS device remembers a failed login attempt.

For an account to be locked, greater than the number of failed login attempts speci­fied by the threshold must occur within the reset time.

10 minutes

Duration

Number of minutes a locked account remains locked. To keep accounts locked until you or another authorized administrator unlocks them, set the value to 0.

10 minutes

Configuring Administrator Lockout Using the GUI

To enable an administrator lockout:

1.     Click System > Admin.

2.     On the Lockout tab, enter values in the Duration, Threshold, and Reset Time fields.

3.     Select the Enable checkbox and click OK.

Configuring Administrator Lockout Using the CLI

You can enter the following commands to configure administrator lockout:

     To enable an administrator lockout, enter the following command:

ACOS(config)# admin-lockout enable

 

     To lock an administrator account, enter the following command:

ACOS(config)# admin-lockout threshold 5

 

This example locks the administrator out after 5 failed attempts.

     To lock out the administrator for a specified number of minutes, enter the following command:

ACOS(config)# admin-lockout duration 15

 

This example locks the administrator out for 15 minutes.

     To keep the administrator account locked until the account is manually unlocked by an authorized administrator, enter the following command:

ACOS(config)# admin-lockout duration 0

 

     To lock the administrator account after, for example, 5 failed login attempts and set the ACOS device to remember the previous failed login for 10 minutes, enter the following commands:

ACOS(config)# admin-lockout reset-time 10

For more information, see TABLE 1   .

To view the lockout status or manually unlock an account:

1.     To view the lockout status of the account for “admin1”, enter the following command:

ACOS(config)# show admin admin1 detail

 

2.     To unlock an admin account, access the configuration level for the admin, then enter the unlock command:

ACOS(config)# admin admin1

ACOS(config-admin:admin1)# unlock

 

Role-Based Access Control

Role-Based Access (RBA) Control is used in conjunction with existing admin accounts to further fine-tune the permissions and privileges for those accounts.

This section contains the following topics:

     Overview of How to Use RBA

     RBA Privilege Levels

     Objects Subject to Access Control

     RBA Configuration Examples

Overview of How to Use RBA

Below is an overview of how to use RBA to configure privileges for a single admin access the ACOS device:

1.     Create an admin account that can be authenticated either locally or remotely using LDAP, RADIUS, or TACACS+.

2.     Enable RBA.

3.     Create an RBA user with the same name as an existing admin user.

4.     Configure the RBA privileges for the user.

RBA privileges for individual users must be set per partition, including the shared partition (see RBA Privilege Levels).

RBA privileges can be applied to any object that can be created using either the CLI or GUI (see Objects Subject to Access Control).

Multiple RBA users can be added as members of an RBA group. You can also configure RBA roles, which define a set of privi­leges. An RBA role can then be applied to individual users or groups.

These instructions are covered in more detail throughout this section.

RBA Privilege Levels

TABLE 2    defines the privilege levels that can be configured using RBA. These privileges can be configured for users, roles, and groups:

TABLE 2       RBA Privilege Levels

Privilege

Description

No Access (Hidden)

The object is hidden from the user or group, is not configurable, and it will not appear in the show running-config command output.

Read

The user or group can view the object but not create, modify, or delete the object. The output for the show running-config command will display the object and its instances.

Write

The user or group has complete access to the object and its instances. You can change, add to, and delete the object instance configurations. The output of the show running-config com­mand will display the object and its instances.

 

Objects Subject to Access Control

RBA enables you configure access privileges for all objects that can be configured in the CLI or GUI. You can configure RBA control for all objects of a particular type, or even a specific object instance.

TABLE 3    shows some examples about specifying objects for RBA control.

TABLE 3       Specifying Objects for RBA Control

Configuration Object

CLI Object Configuration

RBA Control Specification

All SLB objects

N/A

slb privilege

SLB templates

All SLB templates

slb.template privilege

A specific SLB template named “temp1”

slb.template.temp1 privilege

SLB Server

All SLB servers

slb.server privilege

A specific SLB server named “rs1”

slb.server.rs1 privilege

SLB virtual-server

All virtual servers

slb.virtual-server privilege

A specific virtual server named “vs1”

slb.virtual-server.vs1 privilege

SLB virtual-port

All virtual ports

slb.virtual-server.port privilege

A specific virtual port

slb.virtual-server.port.80+tcp privilege

If conflicting privilege levels are configured, the “longest match” takes precedence. For an example, if the following is config­ured:

slb write

slb.virtual-server read

In this example, write access is granted to SLB objects, and read access is granted to SLB virtual-server objects. Because SLB virtual-server is the “longest match”, the read access for those objects takes precedence over the write access that was granted for SLB objects.

There are two ways in which you can configure object privileges using RBA:

     “Additive” RBA, which is more useful for granting admins privileges to access certain objects. For more information, see Understanding “Additive” RBA.

     “Subtractive” RBA, which is more useful to denying admins privileges to access certain objects. For more information, see Understanding “Subtractive” RBA.

Understanding “Additive” RBA

An existing admin user with write privileges is able to create, edit, or delete any object. The “additive” method of RBA involves the following:

1.     Using the root no-access command to overwrite the default write privileges of the admin, thus removing all of the admin’s create, edit, and delete privileges.

2.     Using RBA to selectively “add” the desired privileges.

Consider the following example with admin “admin_so” who has write privileges by default. The admin is able to create a health monitor with the default privileges:

ACOS(config)# health monitor hm1

ACOS(config-health:monitor)# exit

ACOS(config)#

 

The RBA configuration will remove all of the default write privileges (root no-access), and allow only creation of SLB objects (slb write):

ACOS(config)# rba user admin_so

ACOS(config-user:admin_so)# partition shared

ACOS(config-user:admin_so-partition:shared)# root no-access

ACOS(config-user:admin_so-partition:shared)# slb write

 

When “admin_so” tries to configure a health monitor again, they will not be able to:

ACOS(config)# health monitor hm1

Access Denied

ACOS(config)#

But “admin_so” is able to configure SLB objects, as defined by the RBA configuration:

ACOS(config)# slb server rs1 192.168.9.9

ACOS(config-real server)#

 

The user “admin_so” had their default write privileges removed, and SLB privileges “added” back to their profile.

 

Understanding “Subtractive” RBA

An existing admin user with write privileges is able to create, edit, or delete any object. The “subtractive” method of RBA selectively removes a subset of these privileges. Consider the following example with “admin_nt” with default write privi­leges. This user is able to view SLB templates in the show running-config output:

ACOS(config)# show run | inc slb tem

slb template ftp FTP_TEMP1

slb template ftp FTP_TEMP2

slb template HTTP HTTP_TEMP1

...

 

Now, we add the RBA configuration to give no-access privileges to user “admin_nt” for SLB templates:

ACOS(config)# rba user admin_nt

ACOS(config-user:admin_nt)# partition shared

ACOS(config-user:admin_nt-partition:shared)# slb.template no-access

 

When “admin_nt” tries to run the show command again, no SLB template are visible:

ACOS(config)# show run | inc slb tem

ACOS(config)#

 

The admin “admin_nt” will still have all normal privileges to create, edit, or delete all other objects on the device, just not SLB templates as this has been “subtracted” from the user’s privileges.

 

RBA Configuration Examples

This section provides examples of how to configure RBA users, roles, and groups using the GUI and CLI.

The following sections are included:

     Configuring RBA Users

     Configuring RBA Groups

     Configuring RBA Roles

 

Configuring RBA Users

This section provides instructions for configuring RBA users. The RBA user name must be an exact match of an existing admin who can be authenticated either locally or remotely using LDAP, RADIUS, or TACACS+.

The following topics are included:

     Configure an RBA User Using the GUI

     Configure an RBA User Using the CLI

Configure an RBA User Using the GUI

In this example, a user called user1 is created. In partition “companyA,” this user will have write access at the SLB object level, read-only privileges for SLB virtual-servers, but have no-access to SLB servers:

1.     Hover over System in the menu bar, then select Admin from the drop-down list.

2.     Select the RBA tab, then select Users from the drop-down list.

3.     Click Create.

4.     In the Name field, enter user1.

5.     In the Rule List field, configure write access at the SLB level for partition “companyA”:

a.     Select companyA from the Partition drop-down list.

b.     Select slb from the Object drop-down list.

c.     Select write from the Operation drop-down list.

d.     Click Add to add the rule.

6.     Repeat step 5 to add read-only privileges for SLB virtual-servers, but no access to SLB servers, for user1 in partition “companyA”.

gui_rba_create_user.PNG

If there is a configured RBA role that specifies all the permissions that you want to grant the user, you can apply the role at the partition level rather than configuring each privilege separately by using the Role List field instead of the Rule List field on this screen.

Configure an RBA User Using the CLI

To create an RBA user, enter the rba user command at the global configuration level. To specify the partition for which you want to modify permissions, enter the partition command. At the partition configuration level in the RBA user, you can specify the privileges for the user.

Specify the privileges by starting with the highest level and then using a dot (.) to indicate the next level. For example, to configure write access at the SLB object level, read-only privileges for SLB virtual-servers, but have no-access to SLB servers, enter the following commands:

ACOS(config)# rba user user1

ACOS(config-user:user1)# partition companyA

ACOS(config-user:user1-partition:companyA)# slb write

ACOS(config-user:user1-partition:companyA)# slb.virtual-server read

ACOS(config-user:user1-partition:companyA)# slb.server no-access

 

To specify CGN objects, enter cgnv6 instead of slb.

If there is a configured RBA role that specifies all the permissions that you want to grant the user, you can apply the role at the partition level rather than configuring each privilege separately (see Configuring RBA Roles). For example:

ACOS(config)# rba user user1

ACOS(config-user:user1)# partition companyA

ACOS(config-user:user1-partition:companyA)# role role1

 

NOTE:                               If an RBA role is applied to an RBA user, when the role profile is modified, the changes will affect the RBA user’s permissions. If there are conflicting privileges between a user’s individually configured privileges and an RBA role’s privileges, the user’s individual privi­leges are used.

 

Configuring RBA Groups

An RBA group combines users who can be configured with similar privileges. When you modify the permissions in a partition for an RBA group, the permissions are applied to all of the users in that group.

After creating a group, select the users to add to the group or select a partition for which you want to modify the permis­sions. You can add users at any time, so you do not need to create users before creating the group; if you specify a user that does not already exist, the user will be created along with the group. The group’s permissions are configurable for multiple partitions, although each partition must be configured separately.

If there are conflicting privilege levels between the user and the group, then the user’s privileges takes precedence. For example, a group may be configured to have only read access to SLB configurations. If a user in the group has write access to SLB configurations, this user can still modify SLB configurations, but all other users in the group can have read-only privileges.

Configure an RBA Group Using the GUI

This example shows how to configure a group containing two pre-existing users on the system. In partition “companyA,” all users in the group will have write access at the SLB object level, read-only privileges for SLB virtual-servers, but no-access to SLB servers

1.     Hover over System in the menu bar, then select Admin from the drop-down list.

2.     Select the RBA tab, then select Groups from the drop-down list.

3.     Click Create.

4.     In the Name field, enter group1.

5.     In the User field, if you already have RBA users created on the system (see Configuring RBA Roles) you can select the user(s) you want to include in the group. If not, use the New Users field to specify users which will be created for you.

6.     In the Rule List field, configure write access at the SLB level for partition “companyA”:

a.     Select companyA from the Partition drop-down list.

b.     Select slb from the Object drop-down list.

c.     Select write from the Operation drop-down list.

d.     Click Add to add the rule.

7.     Repeat step 6 to add read-only privileges for SLB virtual-servers, but no access to SLB servers.

gui_rba_create_group.PNG

8.     Click Create to create the group.

If there is a configured RBA role that specifies all the permissions that you want to grant the user, you can apply the role at the partition level rather than configuring each privilege separately by using the Role List field instead of the Rule List field on this screen.

Configure an RBA Group Using the CLI

To create an RBA group, enter the rba group command at the global configuration level to assign users, define partitions, and specify privileges.

Specify the privileges by starting with the highest level and then using a dot (.) to indicate the next level. For example, to configure write access at the SLB object level, read-only privileges for SLB virtual-servers, but no-access to SLB servers, you would enter the following commands:

ACOS(config)# rba group group1

ACOS(config-group:group1)# user user1

ACOS(config-group:group1)# user user2

ACOS(config-group:group1)# partition companyA

ACOS(config-group:group1-partition:companyA)# slb write

ACOS(config-group:group1-partition:companyA)# slb.virtual-server read

ACOS(config-group:group1-partition:companyA)# slb.server no-access

 

To specify CGN objects, enter cgnv6 instead of slb.

If there is a configured RBA role that specifies all the permissions that you want to grant to the group, you can apply the role at the partition level rather than configuring each privilege separately. For example, you can enter the following commands:

ACOS(config)# rba group group1

ACOS(config-group:group1)# user user1

ACOS(config-group:group1)# user user2

ACOS(config-group:group1)# partition companyA

ACOS(config-group:group1-partition:companyA)# role role1

 

NOTE:                               If an RBA role is applied to an RBA group, when the role profile is modified, the changes will affect the all of the users in this group.

If there are conflicting privileges between a group’s uniquely configured privileges and an RBA role’s privileges, the group’s unique privileges are used. An individual user’s privi­leges still take precedence over the group privileges.

 

Configuring RBA Roles

Creating an RBA role profile can help simplify the management of permissions. The privileges defined in the role can be applied to any user or any group; when applied to a group, the permissions in the role apply to all members of the group.

You can assign multiple roles to a user or group. If the user or group has individual permissions defined in addition to the role, a combination of the individual and role permissions are applied. If there are conflicting privileges between a role and a user or group, the configured privilege for the individual user or group overrides the privilege that is defined in the role.

Configure an RBA Role Using the GUI

This example shows how to configure an RBA role using the GUI. The role grants write access at the SLB object level, read-only privileges for SLB virtual-servers, but no access to SLB servers:

1.     Hover over System in the menu bar, then select Admin from the drop-down list.

2.     Select the RBA tab, then select Roles from the drop-down list.

3.     Click Create.

4.     In the Name field, enter slb1.

5.     In the Rule field, select slb from the drop-down list on the left, then select write from the drop-down list on the right. This configures write access at the SLB level. Click Add to add the rule.

6.     Repeat step 5 to add read-only privileges for SLB virtual-servers, but no access to SLB servers.

gui_rba_create_role.PNG

7.     Click Create to create the Role.

Configure an RBA Role Using the CLI

To create an RBA role, after entering the rba role command at the global configuration level, you can specify which privi­leges the role defines.

Specify the privileges by starting with the highest level and enter a dot (.) to indicate the next level. For example, to configure write access at the SLB object level, read-only privileges for SLB virtual-servers, but no access to SLB servers, enter the follow­ing commands:

ACOS(config)# rba role slb1

ACOS(config-role:slb1)# slb write

ACOS(config-role:slb1)# slb.virtual-server read

ACOS(config-role:slb1)# slb.server no-access

To specify CGN objects, enter cgnv6 instead of slb.

NOTE:                               If an RBA role is assigned to any RBA user or group, when the role profile is modified, the changes will affect the users and/or groups to which the role profile is assigned.

If there are conflicting privileges between a user’s or group’s uniquely configured privi­leges and an RBA role’s privileges, the user’s or group’s unique privileges are used.

Table of Contents

Index

Glossary

-Search-

Back