man pages section 1M: System Administration Commands

smmultiuser(1M)

NAME

smmultiuser- manage bulk operations on user accounts

SYNOPSIS

/usr/sadm/bin/smmultiuser

subcommand

auth_args

--

subcommand_args

DESCRIPTION

The smmultiuser command allows bulk operations on user entries in the local /etc filesystem or a NIS or NIS+ name service, using either an input file or piped input. Note: Both input files and piped input contain a cleartext (non-encrypted) password for each new user entry.

Note -

The smmultiuser command does not accept Trusted Solaris security attributes, such as labels and clearances. Use smuser(1M) to create a user with Trusted Security attributes or to add such attributes to an existing user.

`subcommands`

smmultiuser subcommands are:

add

Adds multiple user entries to the appropriate files. To add an entry, the administrator must have the solaris.admin.usermgr.write authorization.

delete

Deletes one or more user entries from the appropriate files. To delete an entry, the administrator must have the solaris.admin.usermgr.write authorization.

modify

Modifies existing user entries in the user account database. Here is the list of what can be modified using the modify subcommand:

UserName (only under certain conditions -- see Note 2 in NOTES)
Password (only under certain conditions -- see Note 3 in NOTES)
Description
Primary Group ID
Shell type
FullName

To modify an entry, the administrator must have the solaris.admin.usermgr.write authorization.

OPTIONS

The smmultiuser authentication arguments, auth_args, are derived from the smc(1M) arg set and are the same regardless of which subcommand you use. The smmultiuser command requires the SMC to be initialized for the command to succeed (see smc(1M)). After rebooting the SMC server, the first smc connection may time out, so you may need to retry the command.

The subcommand-specific options, subcommand_args, must come after the auth_args and must be separated from them by the -- option.

`auth_args`

The valid auth_args are -D, -H, -l, -p, -r, --trust, and -u; they are all optional. If no auth_args are specified, certain defaults will be assumed and the user may be prompted for additional information, such as a password for authentication purposes. These letter options can also be specified by their equivalent option words preceded by a double dash. For example, you can use either -D or --domain.

-D | --domain domain

Specifies the default domain that you want to manage. The syntax of domain is type:/host_name/domain_name, where type is nis, nisplus, dns, ldap, or file; host_name is the name of the machine that serves the domain; and domain_name is the name of the domain you want to manage. (Note: Do not use nis+ for nisplus.)

If you do not specify this option, the SMC assumes the file default domain on whatever server you choose to manage, meaning that changes are local to the server. Toolboxes can change the domain on a tool-by-tool basis; this option specifies the domain for all other tools.

-H | --hostname host_name:port

Specifies the host_name and port to which you want to connect. If you do not specify a port, the system connects to the default port, 898. If you do not specify host_name:port, the SMC connects to the local host on port 898. You may still have to choose a toolbox to load into the console. To override this behavior, use the smc(1M) -B option, or set your console preferences to load a "home toolbox" by default.

-l | --rolepassword role_password

Specifies the password for the role_name. If you specify a role_name but do not specify a role_password, the system prompts you to supply a role_password. Passwords specified on the command line can be seen by any user on the system, hence this option is considered insecure.

-p | --password password

Specifies the password for the user_name. If you do not specify a password, the system prompts you for one. Passwords specified on the command line can be seen by any user on the system, hence this option is considered insecure.

-r | --rolename role_name

Specifies a role name for authentication. If you do not specify this option, no role is assumed.

--trust

Trusts all downloaded code implicitly. Use this option when running the terminal console non-interactively and you cannot let the console wait for user input.

If using piped input into any of the smmultiuser subcommands, it will now be necessary to use the --trust option with the -L logfile option. See EXAMPLES.

-u | --username user_name

Specifies the user name for authentication. If you do not specify this option, the user identity running the console process is assumed.

--

This option is required and must always follow the preceding options. If you do not enter the preceding options, you must still enter the -- option.

`subcommand_args`

Note: Descriptions and other arg options that contain white spaces must be enclosed in double quotes.

For subcommand add:

-h

(Optional) Displays the command's usage statement.

-i input_file

Specifies the input file containing the user account information. After the command is executed, the input file is removed. The input file must follow the /etc/passwd file format. If you do not specify the -i input_file option, you must include a piped_input operand immediately before the command. See EXAMPLES.

-L logfile

(Optional) Specifies the full pathname to the text file that stores the command's success/failure data. Note: This text file is an ASCII--formatted log file; it is different from and unrelated to the output of the normal logging mechanism that also occurs within the Log Viewer tool. The -L logfile option is used to dump additional logging information to a text file.
For subcommand delete:

-h

(Optional) Displays the command's usage statement.

-i input_file

Specifies the input file containing the user account information. After the command is executed, the input file is removed. The input file must follow the /etc/passwd file format. If you do not specify the -i input_file option, you must include a piped_input operand immediately before the command. See EXAMPLES.

-L logfile

(Optional) Specifies the full pathname to the text file that stores the command's success/failure data.
For subcommand modify:

-h

(Optional) Displays the command's usage statement.

-i input_file

Specifies the input file containing the user account information. After the command is executed, the input file is removed. The input file must follow the /etc/passwd file format. If you do not specify the -i input_file option, you must include a piped_input operand immediately before the command. See EXAMPLES. Note: When modifying passwords, use the piped input, since it is more secure than keeping passwords in a file. See Note 1 in NOTES.

-L logfile

(Optional) Specifies the full pathname to the text file that stores the command's success/failure data.

OPERANDS

The following operands are supported:

piped_input: You must include piped_input if you do not specify an input_file. Include the piped input immediately before the command. The piped input must follow the /etc/passwd file format. See EXAMPLES. Note: Use the --trust option when using piped input with the -L logfile option to avoid the user prompt from the Security Alert Manager, which normally asks the user whether the log file should be created. Without the --trust option, the piped input is improperly taken as the answer to the prompt before the user can answer "Y" or "N", and the logging operation will probably fail.

EXAMPLES

Example 1 Adding multiple user accounts

The admin role reads in user account data from the /tmp/foo file and creates new user accounts. The input file is formatted in the /etc/passwd format. The administrator is prompted for the admin password.

$ /usr/sadm/bin/smmultiuser add -- -i /tmp/foo

Example 2 Deleting multiple user accounts

The admin role reads in user account data from the /tmp/foo file and deletes the named user accounts. The administrator is prompted for the admin password.

$ /usr/sadm/bin/smmultiuser delete -- -i /tmp/foo

Example 3 Creating a log file with piped input

The following example shows the use of the smc(1M) --trust option that is required when creating a log file. It is applicable to the delete and modify subcommands also.

$ cat /tmp/users.txt | /usr/sadm/bin/smmultiuser add --trust -- \
-L /tmp/mylog.txt

ENVIRONMENT VARIABLES

See environ(5) for a description of the JAVA_HOME environment variable, which affects the execution of the smprofile command. If this environment variable is not specified, the /usr/java location is used. See smc(1M).

EXIT STATUS

The following exit values are returned:

0: Successful completion.
1: Invalid command syntax. A usage message displays.
2: An error occurred while executing the command. An error message displays.

FILES

The following files are used by the smprofile command:

/etc/passwd: Contains the file format to use for the input_file and piped_input. See passwd(4).

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWmga

SUMMARY OF TRUSTED SOLARIS CHANGES

To add, delete, or modify an entry, the administrator must have the solaris.admin.usermgr.write authorization.

Trusted Solaris 8 Reference Manual

smc(1M), smrole(1M), smuser(1M)

SunOS 5.8 Reference Manual

passwd(4), attributes(5), environ(5)

NOTES

The file format used by both the add and modify subcommands is the /etc/passwd format. But there is an allowance for a mutated version of this file format that contains an extra field at the end of each line to be used for the Full Name. If the extra field is appended to the end of each line, it will be used for the Full Name value, but if it is omitted, it will be assumed that no FullName modification is being done. The extra field is separated with a colon (:), just like all the other fields.

Example of regulation /etc/passwd entry:
rick2:x:1011:10:description1:/home/rick2:/bin/sh
Example of /etc/passwd variant entry:
rick2:x:1011:10:description1:/home/rick2:/bin/sh:Ricks_fullname
The modifications are all done based on lookups of the user name in the user tables. If a user name cannot be found in this lookup, a secondary check is made to see if the uid and FullName can be found in the user tables. If they are both found, the user is renamed. If neither can be found, no modification occurs.
If no password is supplied, the password is not changed. If a password is being changed, it should be supplied in cleartext as piped input or in the input file. Once read in, the password is changed accordingly.

Trusted Solaris 8 Last Revised 6 Oct 2000