6.3 Administrative Tools for Managing User Accounts

Shell scripts to automate the user account creation process have been common for a long time on Unix systems, and most Unix vendors/environments also provide graphical utilities for the same purpose. The latter tools allow you to make selections from pick lists and radio buttons and type information into blank fields to specify the various user account settings.

The advantage of these tools is that they take care of remembering a lot of the steps in the process for you. They usually add entries to all relevant account configuration files (including ones related to enhanced security, if appropriate), and they make sure that the entries are formatted correctly. They also typically create the user's home directory, copy initialization files to it, and set the correct ownerships and protection. Most of the tools are extremely easy to use, if somewhat tedious and occasionally time-consuming.

All of these tools also suffer from the same disadvantage: their abilities usually end after completing the activities I've already listed. A few of them perform one or two additional activities adding the user to the mail system is among the most common but that still leaves a lot to do. The best of these tools allow you to customize the activities that are performed, as well as the default values for available account settings; unfortunately, many of the currently available Unix user account management facilities lack any serious customization capabilities.

The best way to use any of these tools is first to set up defaults that reflect how things are done on your system, to the extent that the tool you've chosen allows you to do so. Doing so will minimize the time it takes to add a new user account to the configuration files. Then write a script that you can run by hand after the tool completes its work to automate the rest of the steps required to fully set up a new account.

In this section, we'll consider the most important and useful command-line utilities and graphical facilities for managing user accounts that are available on the Unix systems we are considering.

6.3.1 Command-Line Utilities

Most systems provide something in the way of command-line utilities for manipulating user accounts and sometimes groups. Note that in most cases, user passwords still need to be set separately using the passwd command.

6.3.1.1 The useradd command: HP-UX, Linux, Solaris, and Tru64

Three commands for managing user accounts are provided on many Unix systems: useradd, for adding new accounts; usermod, for changing the settings of existing accounts; and userdel, for deleting user accounts. HP-UX, Linux, Solaris, and Tru64 support these commands.

The useradd command has two modes: defining a new user and setting systemwide defaults. By default, useradd adds a new user to the system, with the desired username specified as its final argument. Other attributes of the user account are specified using useradd's many options, described in the Table 6-6.

Table 6-6. useradd command options

Option	Meaning
-u uid	UID (defaults to next highest unused UID).
-g group	Primary group.
-G groups	Comma-separated list of secondary groups.
-d dir	Home directory full pathname (defaults to current-base-dir/username; the current base directory is itself specified with useradd's -D option, and is usually set to /home). Tru64 also provides the -H option for specifying the home directory base when creating a new user account.
-s shell	Full path to login shell.
-c name	Full name (GECOS field text).
-m	Create user's home directory and copy the standard initialization files to it.
-k dir	Skeleton directory containing initialization files (defaults to /etc/skel); only valid with -m. Not provided by Tru64.
-e date	Account expiration date (default is none); format: yyyy-mm-dd.
-f n	Number of days the account can be inactive before being disabled automatically.
-p	On Tru64 systems, requests a prompt for the user's initial password. On Linux systems, the option requires the encoded password as its parameter, making it useful in scripts where you are importing user accounts from another Unix system's password file, but it is of little use otherwise. Solaris and HP-UX do not provide this option.
-D	Set option defaults using the -f, -e, -g, and -b options (the last option is -d on Tru64 systems). The -s option may also be used on Linux systems, and the -x skel_dir=path option provides the same functionality under Tru64.
-b dir	Default base directory for user home directories (for example /home); only valid with -D. Tru64 uses -d for this function (as well as for its normal role when creating a user account).

Here is the useradd command to create user chavez:

# useradd -g chem -G bio,phys -s /bin/tcsh -c "Rachel Chavez" -m chavez

This command creates user chavez, creates the directory /home/chavez if it doesn't already exist (the home directory's pathname is the concatenation of the base directory and the username), and copies initialization files from /etc/skel to the new directory. It also places chavez in the groups chem, bio, and phys (the first one is her primary group). Her UID will be the next available number on the system.

The Tru64 version of useradd also supports setting some extended attributes using the -x option. For example, the following command sets the valid login hours for user chavez to weekdays during normal U.S. business hours:

# useradd normal options  -x logon_hours=Wk0900-1700 chavez

6.3.1.1.1 Setting useradd's defaults

The -D option tells useradd to set systemwide default values for various account attributes to be used when creating new users. For example, the following command sets the default group to chem, sets the base directory to /abode, and disables the account inactivity feature.

# useradd -D -g chem -b /abode -f -1

You can display the current options by executing useradd -D alone or by examining the command's configuration file, /etc/default/useradd; here is an example file:

GROUP=100 HOME=/home INACTIVE=-1 EXPIRE=2005-01-01 SHELL=/bin/bash SKEL=/etc/skel

Although there is no command option to do so, you can change the default skeleton directory location by editing the SKEL line in the file.

6.3.1.1.2 Modifying accounts with usermod

A user's current attributes may be changed with the usermod command, which accepts all useradd options except -k. The -d and -m now refer to the new home directory for the user (and -m now requires -d). In addition, usermod supports a -l option, used to change the username of an existing user. For example, the following command changes chavez's username to vasquez, moving her home directory appropriately:

# usermod -m -l vasquez chavez

In addition to these commands, the normal chsh and chfn commands available to all users may be used by the superuser to quickly change the login shell and user information fields for a user account, respectively (passwd -e and -g under Solaris).

For example, on a Linux system, the following commands change user harvey's login shell to the Korn shell and specify a variety of information to be stored in the user information field of his password file entry:

# chsh -s /bin/ksh harvey # chfn -f "Harvey Thomas" -o 220 -p 555-9876 -h 555-1234 harvey

User harvey's password file entry now looks like this:

harvey:x:500:502:Harvey Thomas,220,555-9876,555-1234:/home/harvey:/bin/ksh

The various items of information stored within the user information field are separated by commas.

There is no hard-and-fast convention for what the various subfields of the password file user information field should be used for, and different tools use them to hold different information. Accordingly, the format of the chfn command varies somewhat in different Unix versions and even within individual versions. The preceding example was from a Red Hat Linux system; the SuSE Linux version of the command would be:

# chfn -f "Harvey Thomas" -r 220 -w 555-9876 \   -h 555-1234 harvey

In the same way, the GUI tools for managing user accounts also divide this field using different schemes.

6.3.1.1.3 Removing accounts with userdel

The userdel command is used to remove a user account. For example, the following command removes user chavez from the password and shadow password file:

# userdel chavez

The -r option may be added to remove herhome directory and all files within it as well as the account itself.

On Tru64 systems, userdel retires user accounts by default. You must use the -D option to actually delete them.

6.3.1.2 Commands for managing groups

Similarly, the groupadd and groupmod commands may be used to set up and modify new groups (although not their memberships). For example, the following command adds a new group named socio:

# groupadd socio

The new group is assigned the next available user group GID number (greater than 99); alternatively, a specific GID may be specified by adding the -g option to the command.

The following command renames the bio group to biochem:

# groupmod -n biochem bio

A group's GID may also be changed with the -g option to groupmod.

Finally, you can remove unwanted groups in a way analogous to userdel with the groupdel command, which takes the name of the group to be deleted as its argument. Note that this command does not let you remove a group that is serving as the primary group for any user account.

6.3.1.3 The Linux gpasswd command

Linux systems provide the gpasswd command for adding and removing members of groups and for specifying group administrators. For example, the following command adds user chavez to the drama group:

# gpasswd -a chavez drama

In a similar way, the -d option may be used to remove the user from a group.

The -A and -M options are used to specify the list of group administrators and additional group members (allowed to use newgrp) in the group shadow file. For example, the following command designates users root and nielsen as group administrators for the bio group:

# gpasswd -A root,nielsen bio

The list of users specified as the argument to either option is comma-separated and must not contain any internal spaces. Note that these options replace the current settings in /etc/gshadow; they do not add additional users to the existing list.

6.3.1.4 The FreeBSD user account utilities

FreeBSD provides the adduser command for creating new user accounts. It does so by prompting you for all of the required information, as in this example, which creates an account for user zelda:

# adduser -s  Enter username [a-z0-9_-]: zelda  Enter full name []: Zelda Zelinski  Enter shell csh ...  ksh [tcsh]: return Enter home directory (full path) [/home/zelda]: return Uid [1021]: return Enter login class: default []: staff  Login group zelda [zelda]: return Login group is ``zelda''.  Invite zelda into other groups: chem phys bio no [no]: chem  Enter password []: not echoed Enter password again []: not echoed Name:     zelda Password: **** Fullname: Zelda Zelinski Uid:      1021 Gid:      1021 (zelda) Class:    staff Groups:   zelda chem HOME:     /home/zelda Shell:    /bin/tcsh OK? (y/n) [y]: y  Add another user? (y/n) [y]: n 

The command's -s (silent) option provides a less verbose prompt sequence. The opposite is -v, which prompts for default settings for this session before adding users:

# adduser -v  Enter your default shell: csh ...  ksh no [sh]: tcsh  Your default shell is: tcsh -> /bin/tcsh Enter your default HOME partition: [/home]: return Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: return Send message from file: /etc/adduser.message no [/etc/adduser.message]: return Use passwords (y/n) [y]: return ...

Verbose mode also inserts additional prompts for an alternate message file and additional message recipient, and it allows you to add to the generated message before it is sent. The verbose/silent setting for the command is sticky: when neither option is included, it defaults to the last value to which it was set.

Normally, the adduser command generates a mail message for the new user as it creates the account. The default message template is stored in /etc/adduser.message . Here is the default new user welcome message for our new user zelda:

To: zelda Subject: Welcome Zelda Zelinski, your account ``zelda'' was created. Have fun! See also chpass(1), finger(1), passwd(1)

I always modify the standard message file to fix the capitalization error and hideous quoting. This is one case where I don't bother keeping a copy of the original!

adduser's defaults are stored in the /etc/adduser.conf configuration file. Here is an example:

defaultpasswd = yes        Require passwords. dotdir = "/usr/share/skel" send_message = "/etc/adduser.message" logfile = "/var/log/adduser" home = "/home" path = ('/bin', '/usr/bin', '/usr/local/bin') shellpref = ('csh', 'sh', 'bash', 'tcsh', 'ksh', 'no') defaultshell = "tcsh" defaultgroup = USER        This setting enables user-private groups. defaultclass = "users"     Default user class (initially empty). uid_start = "1000"         Lowest UID assigned.

As is noted in the comment, the defaultclass variable is initially unassigned. If you want to have a specific login class assigned to new accounts, you'll need to modify this entry in the configuration file (as we have done above). Userclasses are described in detail later in this chapter.

You can also specify some of these items via adduser options, as in this example:

# adduser -dotdir /etc/skel -group chem -home /homes2 \           -shell /usr/bin/tcsh -class users

The chpass command may be used to modify existing user accounts. When invoked, it places you into a form within an editor (selected with the EDITOR environment variable), where you may modify the account settings. Here is the form you will edit:

#Changing user database information for zelda. Login: zelda Password: $1$dGoBvscW$kE7rMy8xCPnrBuxkw//QH0 Uid [#]: 1021 Gid [# or name]: 1021 Change [month day year]: January 1, 2002       Most recent pwd change. Expire [month day year]: December 31, 2005     Account expiration date. Class: staff Home directory: /home/zelda Shell: /bin/tcsh Full Name: Zelda Zelinski Office Location:                               Additional (optional) GECOS subfields. Office Phone: Home Phone: Other information:

Be sure to modify only the settings data, leaving the general structure of the form intact.

The rmuser command may be used to remove a user account, as in this example:

# rmuser zelda Matching password entry: zelda:*:1021:1021:staff:0:0:Zelda Zelinski:/home/zelda:/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/zelda)? y

The command also removes files belonging to the specified users from the various system temporary directories.

6.3.1.5 The AIX user account utilities

AIX provides the mkuser , chuser , and rmuser commands for creating, modifying, and deleting user accounts, respectively. Their syntax is so verbose, however, that it is usually much easier to use the SMIT tool when adding users interactively.

The mkuser command requires a series of attribute=value pairs specifying the account characteristics, followed at last by the username. Here is an example of using mkuser to add a new user account:

# mkuser home=/home/chavez gecos="Rachel Chavez" pgrp=chem chavez 

Of the standard password file fields, we allow mkuser to select the UID and assign the default shell. mkuser uses the settings in /usr/lib/security/mkuser.default for basic account attribute defaults, as in this example file:

user:         pgrp = staff         groups = staff         shell = /usr/bin/ksh         home = /home/$USER admin:         pgrp = system         groups = system         shell = /usr/bin/ksh         home = /home/$USER

The two stanzas specify defaults for normal and administrative users, respectively. You create an administrative user by specifying the -a option on the mkuser command or by specifying the attribute admin=true to either mkuser or chuser.

Table 6-7 lists the most useful account attributes which can be specified to mkuser and chuser. Password-related attributed are omitted; they are discussed later in this chapter.

Table 6-7. AIX user account attributes

Attribute	Meaning
id=UID	UID
prgp=group	Primary group
groups=list	Group memberships (should include the primary group)
gecos="full name"	GECOS field entry
shell=path	Login shell
home=path	Home directory
login=true/false	Whether local logins are allowed
rlogin=true/false	Whether remote logins are allowed
daemon=true/false	Whether user can use cron or the SRC
logintimes=list	Valid login times
ttys=list	Valid tty locations
loginretries=n	Number of login failures after which to lock account
expire=date	Account expiration date
su=true/false	Whether other users can su to this account
sugroups=list	Groups allowed to su to this account
admin=true/false	Whether account is an administrative account
admgroups=list	Groups this account administers
umask=mask	Initial umask value
usrenv=list	List of initial environment variable assignments (normal user context)
sysenv=list	List of initial environment variable assignments (administrative user context)

The mkuser command runs the mkuser.sys script in /usr/lib/security as part of its account creation process. The script is passed four arguments: the home directory, username, group, and shell for the new user account.

This script serves to create the user's home directory and copy one or both of /etc/security/.profile and an internally generated .login file to it. Here is the .login file that the script generates:

#!/bin/csh set path = ( /usr/bin /etc /usr/sbin /usr/ucb $HOME/bin ... )  setenv MAIL "/var/spool/mail/$LOGNAME" setenv MAILMSG "[YOU HAVE NEW MAIL]" if ( -f "$MAIL" && ! -z "$MAIL") then      echo "$MAILMSG" endif

It is equivalent to the standard .profile file.

You can modify or replace this script to perform more and/or different activities, if desired. For example, you might want to replace the exiting if statement that copies initialization files with commands like these (which use a standard skeleton file directory):

if [ -d /etc/skel ]; then    for f in .profile .login .logout .cshrc .kshrc; do       if [ -f /etc/skel/$f ] && [ ! -f $1/$f ]; then          cp /etc/skel/$f $1          chmod u+rwx,go-w $1/$f          chown $2 $1/$f          chgrp $3 $1/$f       fi    done fi

These commands ensure that the skeleton directory and the files within it exist before attempting the copy. They also are careful to avoid overwriting any existing files.

Because /usr/lib/security may be overwritten during an operating system upgrade, you'll need to save a copy of the new version of mkuser.sys if you modify it.

6.3.1.5.1 Removing user accounts

The rmuser command removes a user account. Include the -p option to remove the corresponding stanzas from all account configuration files rather than just the password file. For example, the following command removes all settings for user chavez:

# rmuser -p chavez

6.3.1.5.2 Utilities for managing groups

The mkgroup , chgroup , and rmgroup commands may be used to add, modify, and remove groups under AIX. Once again, the SMIT interface is at least as useful as the raw commands, although these come in handy once in a while. For example, the following command creates a new group named design and assigns users to it (via secondary memberships):

# mkgroup users=lasala,yale,cox,dubail  webart

6.3.2 Graphical User Account Managers

With the exception of FreeBSD, all of the Unix variations we are considering provide some sort of graphical tool for managing user accounts. Some of them, most notably Linux, offer several tools. We'll consider the most useful of these for each operating system.

6.3.2.1 Managing users with SMIT under AIX

Figure 6-1 illustrates the SMIT user management facilities. The dialog on the left (and behind) displays the Security and Users submenu, and the dialog on the right displays the user account attributes dialog. In this case, we are adding a new user, but the dialog is the same for modifying a user account. The various fields in the dialog correspond to fields within the password file and the various secondary account configuration files within /etc/security.

Figure 6-1. User account management with SMIT

The SMIT facility functions as an interface to the mkuser and related commands we considered earlier, and it is quite obvious which attributes the various dialog fields correspond to. SMIT also uses the same default values as mkuser.

6.3.2.2 Managing users with SAM under HP-UX

Figure 6-2 illustrates the SAM user management facilities on HP-UX systems. The dialog on the left shows the items available by selecting the Accounts for Users and Groups item in SAM's main window. The dialog at the upper left is used to access user account attributes when adding or modifying a user (we are doing the latter here). Its fields correspond to the traditional password file entries.

Figure 6-2. User account management with SAM

The dialog at the bottom of the figure appears as a result of clicking the Modify Password Options button in the main user account window. We'll consider its contents later in this chapter.

You can customize the user account creation and removal processes via the Actions Task Customization menu path from the main user accounts window. This brings up a dialog in which you can enter the paths to scripts to be run before and after creating or removing a user account. The full pathname for the program name must be given to SAM, root must own it, it must have a mode of either 500 or 700 in other words, no group or other access and no write access for root and every directory in its pathname must be writable only by root. (All of these are excellent security precautions to take for system programs and scripts that you create in general.)

The programs will be invoked as follows:

prog_name -l login -u uid -h home_dir -g group -s shell -p password \         -R real_name -L office -H home_phone -O office_phone

SAM also allows you to define user templates: named sets of user account settings that can customize and speed up the account creation process. The Actions User Templates submenu allows templates to be created, manipulated and activated. When defining or modifying a template, you use dialogs that are essentially identical to the ones used for normal user accounts.

Choose the Actions User Templates Select menu item to activate a template (selecting the desired template from the dialog that follows). Once this is done, the template's defaults are used for all new user accounts created in that SAM session until the template is changed or deselected.

Defaults for user accounts created without a template come from the file /usr/sam/lib/C/ug.ui. Search the file for the string "default"; it should be apparent which ones set account attribute defaults. You can change them with a text editor, and the new values will be in effect the next time you run SAM. Note that some defaults (e.g., the home directory base) appear in more than one place within the file. Obviously, you'll need to be careful when editing this file. Copy the original before you edit so that you'll have a recovery path should something break.

6.3.2.2.1 HP-UX account and file exclusion

On HP-UX systems, SAM allows you to specifyuser accounts and files that it should never remove. The file /etc/sam/rmuser.excl lists usernames that will not be removable from within SAM (although they may be retired). Similarly, the file rmfiles.excl in the same directory lists files that should never be removed from the system, even if the account of the user who owns them is removed. Naturally, these restrictions have no meaning except within SAM.

6.3.2.3 Linux graphical user managers

There are a plethora of choices for administering user accounts on Linux systems, including these:

• The Linuxconf facility, a distribution-independent system administration tool

• The Ximian Setup Tools' user accounts module

• The KDE User Manager

• The Red Hat User Manager on Red Hat Linux systems

• The YaST menu-based utility and the YaST2 graphical user account editor on SuSE Linux systems

We'll look at three of these here: Linuxconf and the KDE and Red Hat user managers.

6.3.2.3.1 Managing users with Linuxconf

The Linuxconf package is a graphical system administration tool designed specifically for Linux and available by default on some Red Hat systems. It includes a module for managing user accounts, which may be accessed from its main navigation tree or executed separately and directly by entering the userconf command. Once you select a user (or choose to add a new account), the User information dialog is displayed (see Figure 6-3).

Figure 6-3. Managing user accounts with Linuxconf

The Base info panel allows you to enter information in the traditional password file fields; you may select from predefined lists of groups and login shells to specify those fields. The User ID field is optional; if it is left blank, Linuxconf assigns the next available UID number to a new user account. A user account may also be disabled by deselecting the click box at the top of the form.

On Red Hat systems, this tool automatically creates a user-private group when adding a new user account. It also automatically creates the user's home directory and populates it with the files from /etc/skel. We will discuss the method for modifying the tool's default behavior later in this section.

The Params panel contains settings related to password aging, and we will consider it later in this chapter. The Mail settings panel sets up the user's email account. The final, rightmost panel, Privileges, contains settings related to this user's ability to use the Linuxconf tool for system administration tasks (discussed in Section 7.5).

Once you have finished entering or modifying a user account, use the buttons at the bottom of the dialog to complete the operation. The Accept button confirms the addition or change, and the Cancel button discards it. The Passwd button may be used to set or change the user's password, and the Del button deletes the current user account.

Deleting a user account is done via the dialog in Figure 6-4. It asks you to confirm the operation and also allows you to specify how to deal with the user's home directory. The first option (Archive the account's data) copies the home directory to a compressed tar file in, e.g., /home/oldaccounts,with a name like gomez-2002-04-02-12061.tar.gz, with the first five components filled in with the username, year, month, day and time; the oldaccounts subdirectory is placed under Linuxconf's current default home directory location. After completing this backup operation, the home directory and all of its contents are deleted. The second option simply deletes the home directory and contents without saving them, and the third option leaves the directory and all of its files unchanged.

Figure 6-4. Deleting a user with Linuxconf

Linuxconf provides similar facilities for managing groups.

The defaults for various aspects of Linuxconf user account management may be specified via the Config Users accounts Policies Password & account policies menu path. The resulting dialog is illustrated in Figure 6-5.

Figure 6-5. Specifying Linuxconf account defaults

The lone click box in the dialog specifies whether user-private groups are in use. The next two fields specify the base directory and default permissions mode for user home directories. The next four fields specify scripts to be run when various actions are performed. By default, the first two of these fields are filled in and hold the paths to the scripts that Linuxconf uses when deleting a user account: the first (Delete account command) specifies the script used when a user account and the home directory are simply deleted, and the second (Archive account command) specifies the script used to archive a user home directory and then delete the user account.

I don't recommend modifying or replacing either of these scripts although examining them can be instructive. Instead, use the next two fields to specify additional scripts to be run when accounts are created and deleted. Note that the account creation script runs after Linuxconf has completed its normal operations, and the account deletion script runs before Linuxconf performs its account deletion operations.

The remaining settings in this dialog relate to password aging, and we will consider them later in this chapter.

6.3.2.3.2 The KDE User Manager

The KDE User Manager (written by Denis Perchine) is included as part of the KDE desktop environment. You start this facility by selecting the System User Manager menu path on the KDE main menu or by running the kuser command. Figure 6-6 illustrates the facility's user account properties window.

Figure 6-6. The KDE User Manager

The User Info panel (on the left in the figure) is used to set traditional password file fields as well as the password itself. The highlighted portion appears only when adding a new user account, and it allows you optionally to create the user home directory under /home, copy files from the skeleton directory (/etc/skel), and create a user-private group for the user account. As you can see, the tool also provides an interpretation of the various optional fields of the GECOS field.

The Groups panel displays the user's primary and secondary group memberships.

The third panel in this dialog, labeled Password Management, deals with password aging settings. We will look at it later in this chapter.

The KDE User Manager also provides similar dialog boxes for adding, modifying and deleting groups.

The KDE User Manager has a Preferences panel (reached via the Settings Preferences menu path) that allows you to specify a different default home directory base and login shell, as well as whether to automatically create the home directory and/or copy files from /etc/skel. It also specifies whether the user-private groups scheme should be used.

6.3.2.3.3 The Red Hat User Manager

Red Hat Linux provides its own user management utility (pictured in Figure 6-7). You can invoke it from the menus of the KDE and Gnome desktops as well as with the redhat-config-users command.

Figure 6-7. The Red Hat User Manager

The User Properties dialog of this tool contains four panels. The User Data panel (displayed on the left in the figure) holds the traditional password file entry fields. The Groups panel lists groups of which the user is a member (display on the right). Note that the primary group is not shown because user-private groups are always used and so the primary group name is always the same as the user account name.

The Account Info panel displays information about whether the user account is locked and any account expiration data which has been assigned. The Password Info panel displays password lifetime data (as we'll see).

6.3.2.4 Solaris GUI tools for managing user accounts

On Solaris systems, the Sun Management Console may be used to administer user accounts. The relevant module is accessed via the Infrastructure AdminSuite menu path (and not via the seemingly more obviously named final main menu option). It is illustrated in Figure 6-8.

Figure 6-8. The Solaris AdminSuite user manager

The bottom dialog in the figure illustrates the interface for modifying an individual user account. The General panel (pictured) holds some of the traditional password file information as well as account locking and expiration settings. The other panels are Group (group memberships), Home Directory (specifies the home directory server and directory, whether it should be automounted, and its sharing protections), Password (allows you to set a password and force a password change), Password Options (password aging settings, discussed later in this chapter), Mail (email account information), and Rights (assigned roles, discussed in Section 7.5).

6.3.2.5 Managing user accounts with dxaccounts under Tru64

The Tru64 dxaccounts command starts the user account management facility. It may also be reached via sysman. It is pictured in Figure 6-9.

Figure 6-9. The Tru64 Account Manager

The window at the top of the figure displays icons for the user accounts. The buttons under the menu bar may be used to perform various operations on the selected account.

The window at the bottom of the figure displays the main user account dialog (in this case, we are modifying a user account). It holds the usual password file fields, as well as buttons that may be used to assign secondary group memberships and a password. The check boxes in the bottom section of the dialog allow you to change the location of the user's home directory and to lock and unlock the account.

The Security button is present only when enhanced security is activated on the system. We will discuss its use later.

The Options General menu path from the user icon window allows you to specify default settings for new user accounts. Selecting it results in the dialog shown in Figure 6-10. It allows you to specify minimum and maximum user and group IDs, default primary group, home base directory, shell and skeleton directory locations, and several other settings.

Figure 6-10. Setting user account default values

These default settings are actually stored in the file $HOME/.sysman/Account_defaults. Editing this file often presents a quicker method for setting them.

The Tru64 Account Manager also allows you to define templates for user accounts: named groups of account settings, which can be used as defaults when creating new accounts and which may also be applied to existing accounts as a group. You can view the existing templates via the View Local Templates menu path from the main window (illustrated in Figure 6-11).

Figure 6-11. Tru64 user account templates

When you create or edit a template, you use dialogs that are essentially identical to those used in the Secuirty section for individual user accounts.

Templates are selected and applied via the Template pull-down menu at the upper left of the main user account dialog (see Figure 6-9). For a new account, selecting a template fills in the various fields in the dialog with the value from the template. When you change the template for an existing account or simply reselect the same template, you apply its current settings to the current account.

6.3.3 Automation You Have to Do Yourself

As we've noted, currently even the most full-featured automated account creation tools don't do everything that needs to be done to fully prepare an account for a new user. However, you can create a script yourself to do whatever the account creation tool you choose omits, and the time you spend on it will undoubtedly be more than made up for in the increased efficiency and decreased frustration with which you thereafter add new users.

The following is one approach to such a script (designed for a Linux system but easily adapted to others). It expects a username as its first argument and then takes any of several options, processing each one in turn and ignoring any it doesn't recognize. For space reasons, this approach contains only minimal error checking (but it doesn't do anything very risky, either):

#!/bin/sh  # local_add_user - finish account creation process  if [ $# -eq 0 ]; then            # no username   exit  fi  do_mail=1                        # send mail unless told not to user=$1; shift                   # save username /usr/bin/chage -d 0 $user        # force password change  while [ $# -gt 0 ]; do           # loop over options  case $1 in                       # process each option   "-m")                          # don't send mail       do_mail=0       ;;   "-q")                          # turn on disk quotas       (cd /chem; /usr/sbin/edquota -p proto $user)       ;;   "-p")                          # enable LPRng printer use       # make sure there is a valid local printer group name      if [ $# -gt 1 ]; then          val=`/usr/bin/grep -c "ACCEPT .* GROUP=$2" /etc/lpd.perms`         if [ $val -gt 0 ]; then             # Add user to that printer group            /usr/bin/gpasswd -a $user $2         else            /bin/echo "Invalid printer group name: $2"         fi         shift                    # gobble printer name      else         /bin/echo "You must specify a printer group name with -p"      fi       ;;   "-g")                          # set up application program       /bin/cat /chem/bin/g2k+/login >> /home/$user/.login      /bin/cat /chem/bin/g2k+/profile >> /home/$user/.profile       /chem/bin/g2k+/setup $user       ;;   *)                             # anything else       /bin/echo "Garbage in, nothing out: $1"       ;;  esac shift                            # drop completed option off list done if [ $do_mail -eq 1 ]; then    /usr/bin/mail -s Welcome $user < /chem/sys/welcome.txt fi

At the discretion of the system administrator, this script can add the user to the disk quota facility (see Section 15.6), the LPRng printing subsystem (see Section 13.6), send a welcoming mail message, and configure the account to use an application program. It also forces the user to change his password at his next login. We will consider user passwords and their administration in detail in the next section.