Manual Pages


Table of Contents

NAME

na_useradmin - Administers node access controls.

SYNOPSIS

useradmin user command argument...

useradmin domainuser command argument...

useradmin group command argument...

useradmin role command argument...

useradmin whoami

DESCRIPTION

The useradmin command is used to control node access privileges. For each category of access grantee -- user, group, and role -- privileges can be added or listed. The following definitions apply:

user

An authenticated person who can be placed into one or more groups.

domainuser

A non-local user who belongs to a Windows domain and is authenticated by the domain. This type of user can only be put into groups if CIFS has been set up. These users can use their administrative capabilities via the ONTAP API RPC interface, as well as the telnet, RSH, SSH, and ONTAP API http interfaces.

group

A collection of users and domainusers that can be granted one or more roles

role

A collection of capabilities

capability

The privilege granted to execute commands or take other specified actions

USAGE

useradmin user add login_name [-c comments] -p password <only for rsh command> -n full name -g group1[,group2,...,groupN] -m password min-age -M password max-age

useradmin user modify login_name -n full name [-c comments] [-g group1,group2,...,groupN] -m password min-age -M password max-age

user add and user modify are used to add and modify administrative users. The user name can be up to 32 characters long. The user name can contain any alphanumeric character, a space, or a punctuation character that is not one of:

" * + , / : ; < = > ? [ \ ]

There are other symbols allowed in user, group, and role names, which have issues with the command line. Putting double-quotes around the name should deal with this problem. Some of these symbols include # @ & <space>.

The -p requirement during rsh sessions for add specifies the password for the user. This password must conform to the rules found in the options "security.passwd.rules".

The -g requirement for add specifies which groups contain this user. A user inherits all the privileges of the groups he is in. This option completely replaces this user's current groups with the new ones.

The -c option specifies a comment about the user. Comments about the user should be no longer than 128 characters and should not contain the character `:' (colon).

The -n option specifies the full name of the user. The full name should be no longer than 256 characters, and should not contain the character `:' (colon).

The -m option specifies the minimum allowable age of the user's password (in days) before the user can change it again. This works in conjunction with the option security.passwd.rules.history to make sure that users have unique, non-repeating passwords.

The -M option specifies the maximum allowable age of the user's password (in days). When the user's password expires, the user's status is set to "Password Expired" and the user can only run the "passwd" command.

When you add a user, you will be prompted to create the user's password and then verify it. A password is case-sensitive and defaults with the following restrictions:

- it must be at least 8 characters long

-
it must contain at least two alphabetic characters

- it must contain at least one digit

If the setting of the security.passwd.rules.enable option is off, then the restrictions will not be enforced. See na_options(1) for additional information about this option.

useradmin user delete login_name

user delete can be used to delete any local user except for "root".

useradmin user list [login_name ] [-g group_name ]

user list displays all non-root users if no user name is provided. Specifying a user name displays full information about that user. The -x option displays extended information about users. -g groupname option displays all of the users in a particular group.

The user entries will each be printed in list format as follows:

  Name: fred
  Info: This is a comment for fred.
  Rid: 131343
  Groups: audit

A single user extended format will be printed as follows:

  Name: fred
  Info: This is a comment for fred
  Groups: Administrators
  Full Name:
  Rid: 131343
  Allowed Capabilities: login-*,api-*,cli-*,security-*
  Password min/max age in days: 1/30
  Status: Enabled

The Info field is the comment (or the NT user description), if any, entered for the user.

The Full Name field contains the user's full name. This is generally more descriptive of the user than the user's name.

The Rid is a unique integer associated with each user. This value is generated automatically by ONTAP when the user record is created.

The Groups field displays all of the groups this user is associated with.

The Allowed Capabilities field indicates this user's privileges. "fred" can login through any administrative protocol. This will be discussed further with the role add command.

The Password min/max age in days: field displays the password aging parameters. Min is the minimum number of days that a password must be used and max is the maximum number of days that a password can be used. In this case, "fred" can only change his password at most once a day, and must change his password at least once every 30 days.

The Status field displays the current status of the administrator. This can be: Enabled, Disabled, or Password Expired.

useradmin domainuser add Network login_name -g group1[,group2,...,groupN]

domainuser add is used to add non-local administrative users. The Windows Domain Controller authenticates these users instead of the node. The Network login_name can be a name, a domain\name, or a textual_sid_S-x-y-z. For more information about a Network login_name, please look at the man page for na_cifs_lookup(1).

useradmin domainuser delete Network login_name -g group1[,group2,...,groupN]

useradmin domainuser delete is used to remove a Network login_name from a specific group. This cannot delete the user from the system. Call the useradmin user delete command to delete a local user from the ONTAP node. If a local user is removed from all groups using the domainuser delete command, the local user is automatically placed into the "Administrators" group.

useradmin domainuser list -g group_name

domainuser list is used to list all of the SIDs in a group. To find what username a SID represents, use the cifs lookup command.

useradmin domainuser load
file_name

domainuser load is used to load a new file over the lclgroups.cfg file. This replaces all the current group membership with the membership given in the new file. This functionality is only available if the current user has the security-load-lclgroups capability.

useradmin group add group_name [-c comments] [-r role1[,role2,...,roleN]]

useradmin group modify group_name [-c comments] [-r role1[,role2,...,roleN]]

group add and group modify are used to add and modify administrative groups. The group name has all the restrictions of a user name except a group name can have up to 256 characters.

The -r requirement specifies which roles this group contains. These roles specify a set of capabilities that the group inherits. This option completely replaces this group's current roles with the new ones.

The -c option specifies a comment about the group. Comments for groups have all the restrictions of user comments.

The -f option for modify is only necessary when trying to modify your own group. This option forces the change without a warning.

useradmin group delete group_name

group delete is used to delete administrative groups.

useradmin group list [group_name [-u ]]

group list is used to list administrative groups. Giving a group name lists more detailed output about the group. The -u option lists all of the users in the group.

The user entries will each be printed in list format as follows:

  Name: audit
  Info: Default group for auditing the system.
  Roles: audit

A single group extended format will be printed as follows:

  Name: Administrators
  Info: Default group for all admins created prior to this release.
  Roles: admin
  Allowed Capabilities: login-*,cli-*,api-*,security-*

The fields are very similar to the user fields. A few things of note in this example is the fact that "Administrators" is the default group, and the use of * in the capabilities allow multiple capabilities to be defined in one statement.

useradmin role add role_name [ -c comments ] -a capability1[,capability2,...,capabilityN ]

useradmin role modify role_name [-c comments] [-a capability1,capability2,...,capabilityN]

role add and role modify are used to add and modify administrative roles. The role name has all the restrictions of a user name.

The -a option specifies which capabilities are allowed in this role. This option completely replaces this role's current capabilities with the new ones.

The -c option specifies a comment about the role. Comments for roles have all the restrictions of user comments.

useradmin role delete role_name

role delete is used to delete an administrative role.

useradmin role list [role_name ]

role list is used to list administrative roles. Giving a role name just lists a single role.

The role entries will each be printed in list format as follows:

  Name: none
  Info:
  Allowed Capabilities:

This means that this role does not have any capabilities.

Capabilities:

There are five categories of capabilities: login-*, cli-*, api-*, security-* and compliance-*. A sixth capability, filerview-readonly, is unused and ignored.

The `*' character is used similar to a wildcard, with a couple of restrictions: It must be used at the end of the capability. It must be used alone or in conjunction with one of the categories. If used with cli-, it must be used with the full name of the CLI command.

The login-* category includes logging in via login_telnet, login-console, login-rsh, login-ssh, login_snmp, login-ndmp, login-sp, and login-http-admin.

The cli-* category includes all of the commands that can be run after a user is logged in with telnet, console, rsh, or ssh. The format for this is cli-<command>*, which means allow all the commands and subcommands. (cli-<command> just means the command and NO subcommands.) The capability for a specific command, like exportfs, would have the following syntax: cli-exportfs* This allows command line accesses to the exportfs command and all of its subcommands. cli-export* may look valid but is NOT allowed.

The api-* type includes all of the ONTAP API calls. These commands are only available via login-httpadmin, so in general, any api-* command must also include this login. The format for this is api-<ontap-api-command> which means allow a specific command/subcommand. Here, it is possible to list only subcommands, like api-system-get-info or a command and its subcommands, like api-systemget-*, or even api-system-*.

The security-* type currently only has a few elements:

security-passwd-change-others which is used specifically to control if a user can change another user's password without knowing their previous password. By default, only root and members of the Administrators group have this capability.

security-priv-advanced which is necessary to run advanced commands that are not used for normal administration. Please talk to a NetApp Inc representative before using advanced commands. By default, only root and members of the Administrators group have this capability.

security-api-vfiler Normally a client will send ONTAP APIs directly to a vfiler if it wishes the API to be executed on the vfiler. The security-apivfiler capability is necessary to send ONTAP APIs to the physical node which is to be forwarded to a vfiler for execution. By default, only root and members of the Administrators group have this capability.

security-load-lclgroups which is necessary to run the useradmin domainuser load command. This command changes all group membership. By default, only root and members of the Administrators group have this capability.

security-complete-user-control which is used to allow an admin to add, modify, and delete users, groups and roles with more capabilities than himself. These users typically only have access to the cli-useradmin* and associated commands, though they can give themselves greater permissions. By default, only root and members of the Administrators group have this capability.

The compliance-* category provides compliance capabilities to users in the "Compliance Administrators" group when issuing snaplock commands. This category may not be added to other groups in the system, nor can it be removed from the list of capabilities given to Compliance Administrators. Currently, the only privilege associated in this category is complianceprivileged-delete. A user can be added to the "Compliance Administrators" group only if the system has "telnet.distinct.enable" option set to "on".

The filerview-readonly is unused and ignored.

useradmin whoami displays the username of the user running this command.

Examples

Creating a user who only administers SNMP

  useradmin role add rsh_help -a login-rsh,cli-help*
  useradmin role add snmp_commands -a login-*,cli-snmp*,api-snmp-*
  useradmin group add snmp_admins -r rsh_help,snmp_commands
  useradmin user add wilma -g snmp_admins

This creates two roles, one which can rsh into the node and run the help command, and another which is allowed to log in through any login method and run any SNMP command. The "snmp_admins" group is allowed to log into the node and run the help command through telnet, rsh, SNMPv3, and so on, and make get and get next requests. The user "wilma" inherits these capabilities from the group.

Creating a user who only makes SNMP requests

  useradmin role add snmp_requests -a login-snmp
  useradmin group add snmp_managers -r snmp_requests
  useradmin user add storeMgr -g snmp_managers

This creates a role and group whose only capability is making SNMP requests. The storeMgr client inherits this capability.

Creating/Modifying a user to not have console access

This is a common issue that arises for appliances running in Windows domains. A user without console access cannot execute any node CLI commands. These local users should be placed in local groups (or even no groups at all) that do not have any roles which contain these capabilities. To see if a user has access, list the user and check the Allowed Capabilities. If a user is in a group with the capabilities: "cli-*" and "login-*", then that user has console access. The following command places a user into a group with no capabilities, which will revoke all privileges.

  useradmin user modify myuser -g "Guests"
  useradmin user list myuser

Creating a user who has Service Processor login privileges

The login-sp capability can be used to configure users who have login privileges to the Service Processor (for example RLM). If a user is in a group with the login-sp capability, then that user has Service Processor access. Console redirection from the Service Processor is controlled via console access as described in this document. The following command places sp-user into a group with login-sp capabilities.

  useradmin role add sp-role -a login-sp
  useradmin group add sp-group -r sp-role
  useradmin user add sp-user -g sp-group

Creating a user who only makes NDMP requests

The "Backup Operators" group includes the "backup" role, which contains login-ndmp. Adding a user into that group will permit NDMP requests.

  useradmin user add ndmpuser -g "Backup Operators"

VFILER CONSIDERATIONS

When run from a vfiler context, (for example via the vfiler run command), useradmin operates on the concerned vfiler.

SEE ALSO

na_passwd(1), na_options(1), na_rshd(8), na_snmp(1), na_vfiler(1).

NOTES

For information on node access via rsh, please see na_rshd(8).


Table of Contents