User Account, Password and Authentication CLI Commands

Use these CLI commands to configure user accounts, passwords and authentication.

Set guiuser Authentication

When logging on via CLI with one of the default CLI accounts (guardcli1, ...guardcli5), it is required to run the CLI command, set guiuser, before any GuardAPI commands will work. This authentication is required to prevent users with limited roles in the GUI from gaining unauthorized access to GuardAPI commands.

The use of the guardcli1 ... guardcli5 accounts requires the setting of a local user & password. Use the CLI command, set guisuer, command to reset the guardcli1 ... guardcli5 accounts and then add a local user & password, as shown in the Syntax.

Note: If LDAP authentication is used, the local user & password will be the LDAP user & LDAP password.

Certain CLI commands are dependent on the role of the guiuser. For example, the role of the guiuser (marked when creating a new user from accessmgr view) must be accessmgr in order to access grdapi create_user, grdapi set_user_roles, and grdapi update_user

Syntax

set guiuser <gui_user or LDAP user> password <password or LDAP password>

Example

$ ssh guardcli1@a1.corp.com

IBM Security Guardium , Command Line Interface (CLI)

guardcli1@a1.corp.com's password:

Last login: Thu Nov  4 14:56:34 2012 from 123.a1.corp.com

================================================================

IBM Security Guardium

Unauthorized access is prohibited

================================================================

a1.corp.com> set guiuser johny_smith password 3wel9s887s

ok

a1.corp.com>

create_user

Examples

>grdapi create_user firstName=john lastName=smith

password=pASSW0rd confirmPassword=pASSW0rd email=jsmith@us.ibm.com

userName=john disabled=0

ID=20000

>grdapi set_user_roles userName="john" 
roles="dba,diag,cas,user"

ID=20000

Added role (dba).

Failed to add role (diag). Diag must have one of these roles: cli or admin.

Added role (cas).

Added role (user).

> grdapi set_user_roles userName="john" 
roles="dba,diag,cas,user,cli"

ID=20000

Added role (dba).

Added role (diag).

Added role (cas).

Added role (user).

Added role (cli).

> grdapi update_user userName="john"
email="john.smith@gmail.com"

ID=20000

> grdapi list_users

ID=0

####### User 3 #######

Username: accessmgr

First Name: accessmgr

Last Name: accessmgr

Email:

Disabled: false

####### User 1 #######

Username: admin

First Name: admin

Last Name: admin

Email:

Disabled: false

####### User 33 #######

Username: anon

First Name: anon

Last Name: anon

Email:

Disabled: false

####### User 20000 #######

Username: john

First Name: john

Last Name: smith

Email: john.smith@gmail.com

Disabled: false

####### User 2 #######

Username: bill

First Name: bill

Last Name: green

Email:

Disabled: true

set_user_roles

set_user_roles

Each time that you execute a set_user_roles, you reset the roles of a user. You don't append to the roles. You reset.

When you create a user using GrdAPI, it will create the user with user role. Whenyou set the role, you have to specify all of its roles This is done to enable deletion of existing roles and addition of new roles.

Even in GUI, it displays all roles, in which you can either check or uncheck a role and when you save it, it will save everything that you checked.

What GrdAPI does, is to give user kevin only role INV, where any user must have one of these roles: user, cli, admin, or accessmgr

The correct way to call this GrdAPI is:

grdapi set_user_roles userName="kevin"  roles="user,inv"

Example

> set guiuser accessmgr password ASDFasdf

ok

> grdapi create_user firstName=kevin

lastName=smith password=pASSW0rd confirmPassword=pASSW0rd

email=ksmith@company.com userName=kevin disabled=0

ID=20000

ok

> grdapi set_user_roles userName="kevin" roles="inv"

set_user_roles:

ERR=3700

User must have one of these roles: user, cli, admin, or accessmgr.

Error executing the command

ok

> grdapi set_user_roles userName="kevin"
roles="user,inv"

ID=20000

Added role (user).

Failed to add role (inv). Sorry, before assigning the inv role the user's Last Name must be set to the name of one of the three investigation databases -

INV_1, INV_2, or INV_3 (case-sensitive)

ok

> grdapi set_user_roles userName="kevin" 
roles="dba,diag,cas,user" 

ID=20000

Added role (dba).

Failed to add role (diag). Diag must have one of these roles: cli or admin.

Added role (cas).

Added role (user).

ok

>

show guiuser

This displays the user (by role) of GUI.

Show command

show guiuser

Password Control Commands

Use the following commands to control user passwords, as follows:
  • store password disable - Set the number of days after which an inactive account will be disabled.
  • store password expiration - Set the number of days after which a password will expire.
  • store password validation - Enable or disable the hardened password validation rules.

Account Lockout Commands

Use the account lockout commands to disable a Guardium® user account after one or more failed login attempts. Use these commands to:
  • Enable or disable the feature. See store account lockout.
  • Set the maximum number of login failures allowed an account within a given time interval. See store account strike count and store account strike interval.
  • Set the maximum number of failures allowed an account for the life of the Guardium appliance. See store account strike max.
  • To unlock the admin user account in the event it becomes locked, see the unlock admin command description.

After a Guardium user account has been disabled, it can be enabled from the Guardium portal, and only by users with the accessmgr role, or the admin user.

Example

Enable account lockout, lock an account after 5 login failures within 10 minutes, and set the maximum number of failures allowed to 999.

store account lockout on

store account strike count 5

store account strike interval 10

store account strike max 999

Note:

If the admin user account is locked, use the unlock admin command to unlock it.

If account lockout is enabled, setting the strike count or strike max to zero does NOT disable that type of check. On the contrary, it means that after just one failure the user account will be disabled!

store account lockout

Enables (on) or disables (off) the automatic account lockout feature, which disables a user account after a specified number of login failures.

Syntax

store account lockout <on | off>

Show Command

show account lockout

store account strike count

Sets the number of failed login attempts (n) in the configured strike interval before disabling the account.

Syntax

store account strike count <n>

Show Command

show account strike count

store account strike interval

Sets the number of seconds (n) during which the configured number of failed login attempts must occur in order to disable the account.

Syntax

store account strike interval <n>

Show Command

show account strike interval

store account strike max

Sets the maximum number (n) of failed login attempts to be allowed for an account over the life of the server, before the account is disabled.

Syntax

store account strike max <n>

Show Command

show account strike max

store disable_sha1_passwords

By default, the Guardium GUI user passwords are hashed with a strong password hashing algorithm. The store disable_sha1_passwords CLI command allows admins to remove existing passwords that are weakly hashed from their Guardium appliances.

Note: In an upgrade scenario, this command only removes weak passwords for users who have logged in since the upgrade.

Syntax

store disable_sha1_passwords [true] [false]

The store disable_sha1_passwords true command, must be executed on the Central Manager and all back up Central Managers, if applicable.

Example:

>store disable_sha1_passwords true
> User passwords will now be hashed with a strong password hashing algorithm.
>store disable_sha1_passwords false
> User passwords will now be hashed with a weak password hashing algorithm.
Weak password hashing algorithms may violate your company compliance requirements.

Show Command

Syntax:

show disable_sha1_passwords

The show command returns the current settings for password hashing.

Example:

>show disable_sha1_passwords 
>SHA1 passwords are allowed.
Note: In an upgrade scenario, the show command returns the users who have not logged in since the upgrade.

store password disable

Sets the number of days of inactivity, after which user accounts will be disabled. When set to 0 (zero), no accounts will be disabled by inactivity. At installation, the default value is zero. You must restart the GUI after changing this setting (see restart gui).

Syntax

store password disable <days>

Show Command

show password disable

store password expiration

Sets the age (in days) for user password expiration. When set to -1, the password never expires. For GUI users, when set to 0 (zero), the password never expires. For any other value, the account user must reset the password the first time they log in after the current password has expired. The default value is 90. You must restart the GUI after changing this setting.

Syntax

store password expiration cli <days>

store password expiration gui <days>

Show Command

show password expiration

store password validation

Turns password validation on or off. The default value is on. Running this command restarts the GUI to apply this setting.

When password validation is enabled, the password must be eight or more characters in length, and must include at least one uppercase alphabetic character (A-Z), one lowercase alphabetic character (a-z), one digit (0-9), and one special character from the table. When disabled (not recommended), any length or combination of characters is allowed.

Syntax

store password validation <on | off>

Show Command s

show password validation

Table 1. Special Characters for Guardium Passwords
Character Description
@ Commercial at sign
# Number sign
$ Dollar sign
% Percent sign
^ Circumflex accent (carat)
& Ampersand
. Full stop (Period)
; Semicolon
! Exclamation mark
- Hyphen (minus)
+ Plus sign
= Equals sign
_ Low line (underscore)

store strong_password_enable

Use this command to enable or disable strong password checking. This setting only applies to local passwords and does not affect passwords that are validated against external directories like LDAP. The Guardium GUI will be restarted for the changes to take effect.

The command accepts the following syntax:
store strong_password_enable [on|off]

Use the command show strong_password_enable to see the current setting.

store user password

Use this command to reset the cli user password. To simplify the support process, we suggest that you keep the cli user password assigned initially by Guardium. There is no way to retrieve the cli user password once it is set. If you lose this password, contact Guardium Support to have it reset.

Syntax

store user password

You will be prompted to enter the current password, and then the new password (twice). None of the password values you enter on the keyboard will display on the screen.

The cli user password requirements differ from the requirements for user passwords. The cli user password must be at least eight characters in length, and must contain at least one each of the following types of characters:
  • Lowercase alphabetic characters
  • Uppercase alphabetic characters
  • Special characters from the Guardium passwords table

Running this CLI command will also update the change-time record in the password expiration file.

unlock accessmgr

Use this command to enable the Guardium accessmgr user account after it has been disabled. This command does not reset the accessmgr user account password.

Note: Only users with admin role are allowed to run this CLI command.

Syntax

unlock accessmgr

restart gui

unlock admin

Use this command to enable the Guardium admin user account after it has been disabled. This command does not reset the admin user account password.

Note: Only users with admin role are allowed to run this CLI command.

Syntax

unlock admin

restart gui

Authentication commands

The following commands display or control the type of authentication used.

store auth

Use this command to reset the type of authentication used for login to the Guardium appliance, to SQL_GUARD (i.e. Local Guardium authentication, the default).

Optional authentication methods (LDAP or Radius, for example) can be configured and enabled from the administrator portal, but not from the CLI. See Configure Authentication for more information.

Syntax

store auth SQL_GUARD

Show Command

show auth