About Setting Up User Accounts and Groups

This chapter describes how to set up user accounts and groups in a network environment. The same procedures apply to standalone systems. The methods you use to set up and administer users and groups on a network depend on whether the network is administered through a name service.

Administration Tool enables you to set up user accounts on a local or remote system or in a name service environment. With a name service like NIS+, you can manage network information in a centralized location so that important system information, such as system and user names, do not have to be duplicated on every system in the network.

Using Administration Tool

Use the following Administration Tool applications to manage user account information:

• User Account Manager to set up and maintain user accounts
• ^(R) · Database Manager to set up and maintain UNIX group information

Depending on the name service used on the network, the information defining user accounts and groups is stored in either:

• NIS+ tables
• NIS maps
• Local /etc files

To avoid confusion, all three types of information will be referred to as the passwd or group file, rather than the passwd or group file, table, or map.

---

Note - You can view the information in NIS maps with Administration Tool, but you cannot change the information. Refer to the SunOS 4.1 system documentation for information about how to administer NIS.

---

Before Using Administration Tool

The following hardware and software requirements must be met before using Administration Tool:

• SunOS 5.x software on all systems to be administered.
• A bit-mapped display monitor - Administration Tool's applications can be used only on a system where the console is a bit-mapped screen.
• OpenWindows software. Start OpenWindows, if necessary.

$ /usr/openwin/bin/openwin

Required Access Privileges for Setting Up User Accounts

Table 1-1 describes the required access privileges for setting up user accounts.

Table 1-1

To Set Up User Accounts Using The	The Required Access Privileges Are:
/etc files	Root access or membership in the sysadmin group (GID=14) on the local or remote system.
NIS+ tables	Membership in the sysadmin group (GID=14) in the NIS+ group table. Create and destroy permissions on the NIS+ passwd, group, auto_home, mail_aliases, and cred tables. NIS+ permissions are granted by membership in an NIS+ group.

Traditional UNIX groups and NIS+ groups are separate. See Name Services Administration Guide for instructions on setting up NIS+ groups.

Using Administration Tool

Start Administration Tool from an OpenWindows window as follows.

$ admintool &

Policies for User Accounts and Groups

Your responsibilities for setting up users and groups at your site depend on the size of your company and the configuration of the systems and network. Here are some general suggestions for setting policy to help you administer users and groups:

• Set up a standard way of assigning user (login) names and user ID (UID) numbers for your site. See the next section for more information.
• Develop a method for collecting information. For example, you might design a form that users can fill out when requesting a new account. See "Collect and Record User Information" on page 35.
• If you need to create a new group ID (GID) for new users, create it before you assign users to the group. See "How to Add a Group" on page 22 for instructions.

Set a Standard for User Names and User IDs

User names (login names) let users access their local own systems and remote systems with the appropriate access privileges. Associated with each user name is a user ID number (UID). The UID identifies the user name to any system on which the user attempts to log in. UID numbers are also used by systems to identify the owners of files and directories. The reason for having both names and numbers is that users can remember names better than numbers, while computers process numbers faster than names.

User (Login) Names

You choose a user (login) name for each user account you create. User names must be unique on both local and remote systems. In addition, user names should be unique within your organization, which may span multiple domains.

A particular user name should always refer to the same person. The user name should be consistent across all accounts. If you create user accounts for a single individual on a number of different systems, always use the same user name and user ID. In that way, the user can easily interchange files between systems without ownership problems.

Each new user name must be distinct from any aliases known to the system or to an NIS or NIS+ domain. Otherwise, mail may be delivered to the alias rather than to the actual user.

---

Note - User Account Manager makes sure names are unique within the NIS+ domain.

---

It is helpful to establish a standard way of forming user names, and the names should be easy for users to remember. The name can contain from two to eight letters and numerals. The first character must be a letter, and at least one character must be a lowercase letter. The user names cannot contain underscores.

A simple scheme is to use the first name initial and first seven letters of the user's last name. For example, Ziggy Ignatz becomes zignatz. If that results in duplicate names, you can use the first initial, middle initial, and the first six characters of the user's last name. For example, Ziggy Top Ignatz becomes ztignatz. If that still results in duplicate names, you can use the first initial, middle initial, first five characters of the user's last name, and the number 1, or 2, or 3, and so on, until you have a unique name.

User ID Number

The user ID number (UID) identifies the account to the operating system by number. The number must be a whole number less than or equal to 60000. UIDs are required for both regular user accounts and special system accounts.

Customarily, the numbers for regular user accounts range from 100 through 60000 and the numbers from 0 through 99 are reserved for system accounts. UID 60001 is reserved for the nobody account and 60002 is reserved for the noaccess account.

Although UID numbers 0 through 99 are reserved, you can add a user with one of these numbers. However, it is not recommended that you use them for regular user accounts. By definition, root always has UID 0, daemon has UID 1, and pseudo-user bin has UID 2. In addition, you should give uucp logins and pseudo user logins, like who, tty, and ttytype, low UIDs so they fall at the beginning of the passwd file.

The UID numbers for regular user accounts should be unique across your organization. However, User Account Manager does not prevent duplicate UIDs within an NIS+. Sometimes you may want to use duplicate UIDs. For example, it's easier to clean up after a training class when all the students have the same UID, even though they log in with different user names. Also, you may have to use duplicates when the supply of unique UIDs is exhausted, which can occur in a university setting.

Be careful when you reuse a UID number. Even when a user has left the organization and the user account has been removed, the UID number remains assigned to files and directories created by that user. Confusion could result if you reassign a UID number and then restore old files created by the original user.

As with user (login) names, you should adopt a scheme to assign unique UIDs. Some companies assign unique employee numbers, and administrators add 1000 to the employee number to create a unique UID number for each employee.

Check for Duplicate User Names (Logins) and User IDs

When you use a name service, you should check new user names and UID numbers to be sure they are unique on the network. You can use User Account Manager and Database Manager to check for duplicate entries and display other user and group information in local /etc files, in NIS+ tables, or in NIS maps. When creating new user accounts with User Account Manager, you can't duplicate an existing user name.

Passwords

Encrypted passwords and password aging information are stored in the /etc/shadow file on the local system in the Solaris 2.x environment. The shadow file is in ASCII format and only the superuser has read privileges. See "Adding Users to a System and a Network" on page 17 for more information about the shadow file.

NIS+ password information is stored in the passwd table, which has more stringent access restrictions than the NIS software. See the Name Services Administration Guide for more information on NIS+ security features.

Setting Up Groups

A user group is a collection of users who can share files and other system resources. For example, the set of users working on the same project could be formed into a user group. A user group is traditionally known as a UNIX group. Information about user groups is stored in the group file.

Each group has a GID (group identification number, analogous to the user identification number), which identifies it internally to the system. A group should have a name and a list of user names. User groups can be defined in two ways:

• Primary group membership - is specified by an entry in the GID field in the passwd file. Whenever a new GID appears in the group field of the passwd file, a new group is defined.
• Secondary group membership - is specified by an entry in the group file by group name, GID, and user list. This is the preferred method.

All users belong to at least one group, their primary group, which is identified by the group field of their user account. When you use User Account Manager to add user accounts, you must specify the user's primary group; otherwise, the default primary group is nobody.

Users can belong to up to 16 secondary groups. To belong to a secondary group, the user must be added to the groups' member list, which User Account Manager does automatically.

The groups command shows the groups a user belongs to. A user can have only one primary group at a time. However, the user can temporarily change the primary group (with the newgrp command) to any other group in which he or she is a member.

Some applications, like the file system, look only at the user's primary group. For example, ownership of files accounting data reflect the primary group, not any secondary groups. Other applications may take into account a user's secondary memberships. For example, a user has to be a member of the sysadmin group to use the Administration Tool, but it doesn't matter if sysadmin is his or her current primary group.

User groups probably are best known as the groups referred to by the read-write-execute permissions for the user, group, and world on files and directories. These permissions are a cornerstone of security. You can't access others' files (that do not allow world access) unless your primary or secondary

group has permission to access the files. For example, a group called techwrite could be created for technical writers, and a central directory of document files could be set up with write permission for the techwrite group. That way, only writers would be able to change the files.

User groups can be local to a system or used across a network. Across the network, user groups allow a set of users on the network to access a set of files on a without making those files available to everyone.

UNIX User Groups

By default, all SunOS 5.x systems have these groups:

root::0:root other::1: bin::2:root,bin,daemon sys::3:root,bin,sys,adm adm::4:root,adm,daemon uucp::5:root,uucp mail::6:root tty::7:root,tty,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon sysadmin::14: nobody::60001: noaccess::60002:

---

Note - You should add authorized users to the sysadmin group (GID=14) in the group file if you want them to administer systems using Administration Tool.

---

Creating New Groups

Many system administrators frequently create new group accounts. In the case of secondary groups, you must create the group and assign it a GID number before you can assign users to it.

User groups can be set up and administered by the system owner who wants to maintain the system files locally if he or she has root privileges. You can set up user groups on a network by duplicating the information in the local /etc/group file on each system. This approach makes updates difficult. A better approach is to use a name service, like NIS+, to maintain a network-wide group table. This also requires that the nsswitch.conf file is set up properly on each system. Either way, you should use the Administration Tool's Database Manager to create and maintain groups.

If you add a user to a group, either manually or by using Database Manager, and the user has NIS+ credentials, you must run the nisaddcred local command again to update the entry in the cred table. This step is not necessary when you use User Account Manager to add a user to a group.

Home Directory

The home directory is the portion of a file system allocated to a user for storing private files. The amount of space you allocate for a home directory depends on the kinds of files the user creates and the type of work done. Allocate at least 15 Mbytes of disk space for each user's home directory.

A home directory can be located either on the user's local system or on a remote file server. In either case, by convention the home directory is created as /export/home/username. On a large server that supports many home directories, there may be many different directories under /export, like home1, home2, home3, and so on, to store users' home directories. Each of these /export/homen directories should use a separate file system. Regardless of where their home directory is located, users usually access their home directories through a mount point named /home/username.

The preferred procedures described in this chapter assume the user's system is on a network and that the Automounter makes the home directory accessible. It makes no difference whether the home directory is on the user's local system or on a remote file server. You can just think of the client and the server as being the same system when the home directory is on the user's local system.

If a user's home directory resides on a server, the file system or directory is made available to the user's system using the share command. User Account Manager does not perform this step for you. You normally do this once as part of setting up the home directory servers on the network.

In addition, you need to define how the home directory is mounted by either:

• Adding an entry to the auto_home auto_home file so that the home directory is automatically mounted. Automounting is the preferred method. The User Account Manager automatically adds the required entry in when you choose the AutoHome Setup option.

or

• Adding an entry in /etc/vfstab file on the user's system to manually mount the home directory.

To support automatic mounting of home directories, the SunOS 5.x system software includes the auto_master file, which has the following entry:

/home auto_home

This entry tells the Automounter to mount the directories specified in the auto_home file on the /home mount point on the local system. The entries in auto_home have the following format:

username system-name:/export/home/username

When a user logs in with username, the Automounter mounts the specified directory (/export/home/username) from the server (system-name) on the /home mount point on the system where the user has just logged in.

This method works even when the home directory is stored on the same system the user has logged in to. But more importantly, this method allows the user to log in to another system and have his or her home directory mounted on /home on that system.

To use the home directory anywhere on the network, it should always be referred to as $HOME, not as /export/home/username. The latter is machine-specific. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x), so the links will be valid no matter on which system the home directory is mounted.

---

Note - When the Automounter is used to mount home directories, you are not permitted to create any directories under the /home mount point on any system. The system recognizes the special status of /home when the Automounter is active.

---

Initialization Files

The characteristics of a user's working environment are determined at login. First, the login program sets a number of variables, like HOME, LOGNAME, and TZ. Then a file called the system profile (an initialization file) is run to set system-wide defaults like PATH, message of the day, and umask. Finally, a file (or two) called the user profile (another initialization file) is run that sets variables specific to the user. For example, the user profile may modify the PATH to include applications that only the user runs.

In addition to the system profile in the /etc directory on each system, each user may have one or more initialization files in their home directory. User Account Manager gives you the option to copy the user initialization files from a specified "skeleton" directory into the user's home directory.

The user initialization files set the search path, environment variables, windowing environment, and other characteristics of the user's environment, which are required to get the user up and running. The content of the user's initialization files is affected by the shell that is assigned to him or her.

You define the default shell for each user when you create each user's account. You can easily change the default shell by changing the appropriate field of a user's entry in the passwd file.

Part of setting up a user's home directory is providing initialization files for the shell specified in the user's passwd entry. Each shell has its own initialization file (or files), which are shown in Table 1-2.

Table 1-2

Shell	Initialization File	Purpose
Bourne	$HOME/.profile	Defines user's environment at login
C	$HOME/.cshrc	Defines user's environment for all C shells invoked after login shell

Table 1-2 (Continued)

Shell	Initialization File	Purpose
	$HOME/.login	Defines user's environment at login
Korn	$HOME/.profile	Defines user's environment at login
	$HOME/$ENV	Defines user's environment at login in the file specified by the Korn shell's ENV environment variable

The SunOS 5.x system software provides default user initialization files for each shell in the /etc/skel directory on each system, as shown in Table 1-3. You can use these as a starting point and modify them to create a standard set of files that will provide the user environment common to all users. After adding a user account, you can customize a specific user's initialization files.

Table 1-3

Shell	File Name
C	/etc/skel/local.login
C	/etc/skel/local.cshrc
Bourne or Korn	/etc/skel/local.profile

When you add a user, the initialization files for the appropriate shell must be copied from where you locate them to the user's home directory. You may want to set up a separate "skeleton" directory for each shell so that you do not need to delete extraneous files when you set up each user. If you want User Account Manager to populate a user's home directory with the appropriate initialization files, both the home directory and the "skeleton" directory must reside on the same system. Note that this is the system where the home directory originates, rather than the system where it eventually gets mounted. Normally, you would set up a system (or a few systems) to serve the home directories on the network.

System Initialization File

When users log in with valid user names and passwords, a system initialization file is run for each user's default shell. Each shell has its own system initialization file (or files), which are shown in Table 1-4.

Table 1-4

Shell	System Initialization File
Bourne	/etc/profile
C	/etc/.login
Korn	/etc/profile

The system initialization file is an executable ASCII file that typically performs these actions:

• Defines and exports some environment variables
• Displays the message of the day
• Displays a list of news items if the user is not root
• Displays a message about mail items if the user has mail
• Defines the default permission for new files (umask 022)

You can edit the system initialization file to change existing definitions. For example, you can change the value assigned to your system mask from 022 to 077 to make files and directories created by users more secure. You can change the default PATH to provide access to locally developed commands.

You can also edit the system initialization file to automate certain routines. For example, you can add shell commands to display the current time and date, and tell users the number of people logged in.

To minimize your work, set system-wide default variables in the system initialization file rather than in the user initialization file.

User's Initialization Files

After the system runs the system initialization file, it runs the user's initialization files. The user's profile is one or more executable ASCII files that executes commands and shell scripts in the same way that the system profile does. In particular, the user's initialization file sets the user's home path, the search path, and other environment variables.

SunOS 5.x software provides default initialization files for the Bourne, C, and Korn shells in the /etc/skel directory. Starting with these default files, you can create your own standard versions to be copied into the user's home directory.

To minimize your work, set system-wide default variables in the system profile. That way you must maintain only two files (/etc/profile and /etc/.login) per system. Maintaining customized versions of user initialization files is time consuming. You may want to make some changes to the user initialization file supplied with SunOS 5.x system software, but after that, you should convey to users that they are responsible for changes specific to their own needs. For example, a user who needs to use an application would add it to his or her PATH environment variable.

Do not add specific references to the local system in the user's initialization file. You want the instructions in the initialization file to be valid regardless of the system to which the user logs in. For example:

• To make a user's home directory available anywhere on the network, always refer to the home directory with the variable $HOME. $HOME works even when the user logs in to another system.
• To access files on a local disk, use global path names, like /net/machine-name/directory-name. When the NIS+ auto_master and hosts files are set up properly on the network, any directory referenced by /net/machine-name can be mounted automatically on any system on which the user logs in.

Password, Shadow, and Group File Information Summary

Fields in the Password File

The fields in the passwd file are separated by colons, and contain the following information:

user-name:password:uid:gid:comment:home directory:login-shell

For example:

kryten:x:101:100:Kryten Series 4000:/export/home/kryten:/bin/csh

The table below describes the passwd file.

Table 1-5

Field Name	Description
user-name	Contains the user or (login) name. User names should be unique and consist of 2-8 letters (A-Z, a-z) and numerals (0-9). The first character must be a letter, and at least one character must be a lowercase letter. User names cannot contain underscores.
password	Contains an x, a placeholder for the encrypted password. (Password is an obsolete field.). The encrypted password is stored in the shadow file.
uid	Contains a user identification number that identifies the user to the system. UIDs for regular users should range from 100 to 60000. All UID numbers should be unique.
gid	Contains a group identification number (GID) that identifies the user's primary group. Each GID must be a whole number between 0 and 60002 (60001 and 60002 are assigned to nobody and noaccess, respectively).
comment	Usually contains the full name of the user. (This field is informational only.) It is sometimes called the GCOS field because it was originally used to hold the login information needed to submit batch jobs to a mainframe running GECOS (General Electric Computer Operating System) from UNIX systems at Bell Labs.
home directory	Contains user's home directory pathname.
login shell	Contains the user's default login shell, which can be /bin/sh, /bin/csh or /bin/ksh. Table 1-12 on page 36 contains a description of shell features.

Fields in the Shadow File

The fields in the shadow file are separated by colons, and contain the following information:

user-name:password:lastchg:min:max:warn:inactive:expire

For example:

rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978

The table below describes the shadow file.

Table 1-6

Field Name	Description
user-name	Contains the user or (login) name.
password	May contain the following entries: a 13-character encrypted user password; the string *LK*, which indicates an inaccessible account, or the string NP, which indicates no password for the account.
lastchg	Indicates the number of days between January 1, 1970 and the last password modification date.
min	Contains the minimum number of days required between password changes.
max	Contains the maximum number of days the password is valid before the user is prompted to specify a new password.
inactive	Contains the number of inactivity days allowed for the user before the user's account is locked.
expire	Contains the absolute date when the user account expires. If exceeded, the user cannot log in to the system.

Fields in the Group File

The group database file contains the following fields:

group name:group password:gid:user-list

For example:

bin::2:root,bin,daemon

The table below describes the group file.

Table 1-7

Field Name	Description
group name	Contains the name assigned to the group. For example, members of the chemistry department in a university may be called chem. Group names can have a maximum of nine characters.
group password	The Group Password field is a relic of earlier versions of UNIX. It is usually left empty or filled with an asterisk. If a group has a password, the newgrp command prompts users to enter it. However, there is no utility to set the password.
group ID (gid)	Contains the group's numeric ID. It must be unique on the local system, and should be unique across the entire organization. Each GID number must be a whole number between 0 and 60002 and numbers under 100 are reserved for system default group accounts). User groups range from 100 to 60000. (60001 and 60002 are assigned to nobody and noaccess, respectively.)
user-list	Contains a list of groups and a comma-separated list of user names, representing the users' secondary group memberships. Each user can belong to a maximum of 16 secondary groups.

Adding Users to a System and a Network

User Account Manager is a graphical user interface that enables to you to easily add user account information using these steps:

• Identify the user to the system and network by entering user information into the passwd file
• Define the user's primary group and optional secondary groups
• Create a password (optional, but highly recommended) and assign the account password aging and expiration attributes
• Create the user's home directory or specify an existing directory pathname
• Create the entry in the auto_home file that enables the user's home directory to be automatically mounted
• Set up the user's home directory with initialization files
• Specify the location of the user's mailbox
• Set up NIS+ credentials

One of User Account Manager's key features is setting up automounting of the user's home directory. The AutoHome Setup option enables users to log in to any system and have their home directories immediately available. This feature requires the appropriate settings in the /etc/nsswitch.conf files on the target systems. If you do not choose to set up automounting, you must manually set up the mounting required to make a user's home directory available on the network.

In addition to setting up the user's account, you may want to customize the working environment by:

• Enabling a default printer
• Modifying initialization files
• Setting up localization requirements

When entering the user account information, you must assign a primary group or accept the default: nobody. The primary group should already exist (if it doesn't exist, specify the group by GID). User names are not added to the member list of the primary group. If they were, the list might become too long. You can also specify optional secondary groups, in which case the user name is added to the member list. Secondary groups must exist beforehand.

Instructions for Setting Up User Accounts and Groups

This section provides step-by-step instructions for performing tasks related to setting up user accounts and groups.

The tasks are shown in the order in which you perform them, except you may want to add groups before adding user accounts. The first task of setting up the system and initialization (skeleton) files is a one-time job. After you set up the initialization files and store them on a server, User Account Manager can copy the user initialization files into the home directories of newly created user accounts.

With User Account Manager, all the steps required to add a user account are incorporated into the Add User and Copy User options under the Edit menu. If you chose to have the home directory automounted, the new user is ready to log in and work from anywhere on the network. If you do not choose to take advantage of automounting, after adding the user account with User Account Manager, you still must set up mounting, so the user can access his or her home directory.

Setting Up Initialization (Skeleton) Files

Prerequisites

• Root access on systems where initialization files will be modified.

Information You Need

• Name of servers on which files are located
• Name of directory storing system initialization file
• Name of directories storing shell-specific user initialization files
• Parameters of environment variables to be set

· How to Set Up the System Initialization File

1. Choose the system that will keep the standard version of the system initialization file you want to use for all other systems.

   Typically this is the same system from which you export home directories.

2. Edit /etc/profile.

   This is the system initialization file used when the user's login shell is the Bourne or Korn shell. Change the contents of the file to include commands, shell scripts, and variable definitions.

3. Edit /etc/.login.

   This is the system initialization file used when the user's login shell is the C shell. Change the contents of the file to include commands, shell scripts, and variable definitions.

4. Copy the two system initialization files to the /etc directory on each system in the network.

cp /etc/.login /net/system_name/etc/.login

· How to Set Up the User Initialization File

1. On the system to be used as a server for home directories, log in as, or become superuser.

   This must be the system where the home directories are created and shared under /export/home, because User Account Manager restricts you to using the same system as the repository of the user initialization files and the sharer of the home directories.

2. Copy the default files from /etc/skel/local.* to separate shell-specific directories, as follows:

   These shell-specific directory names are what you enter in the Skeleton Path field in the Add User or Copy User window under User Account Manager.

   a. Create the three shell-specific directories.

# mkdir /etc/skel/C; mkdir /etc/skel/B; mkdir /etc/skel/K

b. Copy the C shell script into the /etc/skel/C directory.

# cp /etc/skel/local.cshrc /etc/skel/C/.cshrc

c. Copy the login script into the /etc/skel/C directory.

# cp /etc/skel/local.login /etc/skel/C/.login

d. Copy the Bourne shell script into the /etc/skel/B directory.

# cp /etc/skel/local.profile /etc/skel/B/.profile

e. Copy the Bourne shell script into the /etc/skel/K directory.

# cp /etc/skel/local.profile /etc/skel/K/.profile

3. Edit cshell_directory/.cshrc.

   This is the C shell initialization file that is run every time the user invokes a C shell after initial login. Change the contents of the file to include commands, shell scripts, and variable definitions.

4. Edit cshell_directory/.login.

   This is the C shell login file that is run once when the user logs in. Change the contents of the file to include commands, shell scripts, and variable definitions.

5. Edit bourneshell_directory/.profile.

This is the Bourne shell initialization file that is run once when the user logs in. Change the contents of the file to include commands, shell scripts, and variable definitions.

6. Edit kornshell_directory/.profile.

This is the Korn shell initialization file that is run once when the user logs in. Change the contents of the file to include commands, shell scripts, and variable definitions.

7. In each shell-specific directory, type chmod 744 .* and press Return. Permissions are set for the initialization files.

---

Note - Although it is not strictly part of setting up the initialization files, while you are working on the home directory server, you should make sure the server is sharing the home directories. For instructions, turn to "Changing a User's Home Directory" on page 49.

---

Adding a Group

Prerequisites

• Start OpenWindows, if necessary
• Start Administration Tool, if necessary
• Verify required access privileges

See "Before Using Administration Tool" on page 3 for more information.

Information You Need

• Group name to give to the new group
• Group ID (GID) to use for the new group
• User names and associated group names

· How to Add a Group

1. Start Database Manager, select the group file, then select the name service in effect on your network, and click on Load.

   The Database Manager main window displays.

2. (Optional) Scroll through the list or use the View (Sort and Search) options to view group entries.

   This lets you see which groups are defined before you add a group. At first, the group entries are sorted by Group Name.

---

Note - The nogroup entry serves a purpose in heterogenous networks running both NIS and NIS+. It is used by the NFS software. If you have a network running only NIS+, this entry is not needed.

---

3. Choose the Add Entry option from the Edit menu.

   The Add Entry window appears.

4. Type the Group Name and the Group ID in the appropriate text fields.

   If you make a mistake or change your mind, click on the Reset button and retype the information.

5. Click on Add.

   The group is added to the group file. Repeat steps 1 through 5 to add more groups. In addition, if you are not using a name service and want to add the groups on other systems, you also must repeat step 1, and specify a different system (host) name in the Use /etc files on host: field in the Load Database window.

If possible, create secondary groups before you add user accounts that refer to those groups. When you add a user account with User Account Manager and assign the user to secondary groups, the user's NIS+ credentials are updated automatically.

Adding a User Account

Prerequisites

• Start OpenWindows, if necessary
• Start Administration Tool, if necessary
• Verify required access privileges

See "Before Using Administration Tool" on page 3 for more information.

Information You Need

• User (login) name
• User ID (UID)
• Primary group ID (GID)
• Secondary group memberships, if any
• Identifying information (name, office, extension, home phone)
• Home directory name
• Login shell program name

· How to Add a User Account

1. If not done already, set up the system and user initialization files.

   The User Account Manager can then automatically copy these files into a user's home directory.

2. Click on the User Account Manager icon.

   User Account Manager allows you to set up and administer user accounts. The window for indicating which type of name service you have appears.

3. Choose the name service in use on your network.

4. Click on Apply.

   The User Account Manager main window appears. The following example reflects a choice of NIS+ as the name service and the default of showing all user entries.

5. Select Add User from the Edit menu.

   After you have added a prototype user, you may find it preferable to add new users with the Copy User option under Edit, instead of the Add User option. The input windows are the same. All of the fields in the Copy User window, except User Name, User ID, and Password, are automatically filled in from the existing user account.

   The Add User window appears.

6. In the User Name field, type the user's login name.

   Choose a name unique to your organization. The name can contain from two to eight letters and numerals. The first character must be a letter, and at least one character must be a lowercase letter. The name cannot contain underscores.

7. In the User ID field, type a decimal number to identify the user.

   Choose a number between 100 and 60000 that is unique within your organization.

8. In the Primary Group field, type the group name or a decimal number identifying the user's primary group.

   If the group does not exist, you must enter a number, rather than a name.

9. (Optional) In the Secondary Group field, type the names or numbers of additional groups to which the user will belong, separated by spaces.

   The referenced group(s) must exist beforehand.

10. In the Comment field, type useful information about the user.

    You can indicate the user's full name, phone number, department, and so on, for informational purposes only.

11. On the Login Shell button, make your choice from the pull-down menu.

    The default login shell is the Bourne shell unless you specify a different shell. If the shell program you want to select is not listed or does not have the exact path name shown, select Other and enter the path name in the adjacent text field.

12. On the Password button, specify your password status from the pull-down menu.

    The choices for password status are described in Table 1-8. By default the password status is set to Cleared until first login. If you choose Normal password, a pop-up window appears in which you type an asterisk-echoed password twice. With NIS+, a colon (:) is not allowed in the password.

    Table 1-8 Password Status Choices in User Account Manager

Password Status	Description
Cleared until first login	(Default) Account does not have a password;user is prompted for password on first login, unless passreq=no is set in /etc/default/login.
Account is locked	Account is disabled with an invalid password and can be unlocked by assigning a new password. This type of account allows a user to own files but not to log in.
No password -- setuid only	Account cannot be logged in to directly. This allows programs like lp or uucp to run under an account, without allowing a user to log in.
Normal password...	Account will have a password, which you set in the pop-up window that appears.

13. (Optional) In the remaining Account Security fields, enter values to set the account security.

    Use the descriptions of the Account Security fields in Table 1-9 to decide which values to set. In the case of Expiration Date, there are separate pull-down menus for day, month, and year.

    Table 1-9 Account Security Fields in the Add User Window

Field	Description
Min Change:	The minimum number of days allowed between password changes, which is intended to prevent a user from changing his or her password and then changing it back a few seconds later. Default is 0.
Max Change:	The maximum number of days the password is valid before it must be changed; otherwise, the account is locked. Blank means the password never has to be changed.
Max Inactive:	The maximum number of days an account may go without being accessed before it is automatically locked. Blank means the account remains active no matter how long it goes unused.
Expiration Date:	Date the user account expires. None means no expiration.
Warning:	Number of days to begin warning the user before the password expires. Blank means no warning is given.

14. (Optional) Click on the Create Home Dir check box to have the user's home directory automatically created.

    Use the Path and Server fields to point to an existing directory, or to specify a new directory to create. In the latter case, the Skeleton Path and Permissions become active. User Account Manager must be installed on the system where the home directory is to be created.

15. In the Path field, type the path of an existing home directory or one to be created.

    The path name refers to the directory on the server, not a remotely-mounted directory. In the standalone case, the server and the user's system are the same. By convention, home directories should be named

    /export/homen/username. Add User creates the directory on the system specified in the next field. The path name of the home directory is stored in

the passwd file exactly as specified, unless AutoHome Setup is checked. If you choose to take advantage of automounting, the mount point, /home/username, is stored.

16. In the Server field, type the server name where the home directory will reside.

    The server must have User Account Manager installed on it.

17. (Optional) In the Skeleton Path field, type the path to the directory that stores the user initialization (skeleton) files that will be copied into the user's home directory.

    If you fill in this field, the shell-specific initialization files are copied from the specified skeleton path directory on the designated server to the specified home directory on the server. The initialization files and home directories must be located on the same (server) system.

18. (Optional) Click on the AutoHome Setup check box if you want automounting to be set up.

    Automounting enables the user's home directory to be automatically mounted under /home/username on any system in the network. The information required for such mounting is stored in the auto_home file. The AutoHome Setup field does not run the share command on the server to export the /export/home directory under which the home directories for multiple users may be kept. Normally, you would do that in setting up the home directory server on the network.

19. Click on the Permissions check boxes to set the Read, Write, and Execute permissions for the user's home directory.

    Permissions can be set only when you are creating a home directory.

20. (Optional) In the Mail Server field, type the host name of the system where the user's mailbox is to reside.

    This creates an entry (username@mail-server-name) in either the NIS+ mail_aliases table or the local /etc/aliases file that identifies where the user's mail will be directed--typically his or her desktop system.

21. (Optional) Click on the Cred. Table Setup check box click if you want the user to be added to the NIS+ cred table.

    This field appears only if you have selected NIS+ as the name service. As part of NIS+ security, users should be added to the cred table so their identities can be authenticated.

22. Click on Add.

    The user information is added to the passwd, group, auto_home, mail_aliases, and cred (tables or local /etc files), accordingly. If you get a message that contains "cannot execute method, access denied," edit the NIS+ group table or the /etc/group file and add your user name to the sysadmin group, whose GID is 14.

23. If you are not using a name service, repeat this procedure for each system that will have the user account.

    Completing the User Setup: To customize the user environment, set environment variables in the user's initialization files, provide access to printing services, and mount the user's mailbox from a remote mail server.

Mounting a User's Home Directory

Prerequisites

• Start OpenWindows, if necessary
• Start Administration Tool, if necessary
• Verify required access privileges

See "Before Using Administration Tool" on page 3 for more information.

Information You Need

• User's login name
• Name of the home directory to be mounted

Either set up automounting for the home directory, or mount the home directory manually, as described below.

---

Note - Using the Automounter with the NIS+ auto_home table is an efficient way to make users' home directories available anywhere on the network.

---

· How to Automount the Home Directory

Use User Account Manager to set up automounting of home directories when you add or modify a user account.

---

Note - The following steps apply whether the home directory is created on the local system or on a remote file server.

---

1. Click on the Database Manager icon.

   The Load Database window is displayed.

2. If necessary, select Auto_home by clicking on the Auto_home entry.

   The Auto_home entry is highlighted.

3. Choose the name service used to administer the network by clicking on the appropriate check box.

4. Click on Load.

   The Auto_home Database window is displayed.

5. Choose the Add Entry option from the Edit menu.

   The Add Entry window is displayed.

6. Type username in the User Name text field.

7. Type system-name:/export/homen/username in the Path text field. When the home directory is located on the user's system, the system-name is the user's system. More often, system-name will be the name of a file server.

8. Click on Add.

   The information is added to the auto_home file. The first time the user logs in, his or her home directory is automatically mounted under /home/username.

9. If you are not using a name service, repeat this procedure to update the

   /etc/auto_home file on each system that will have the user account.

· How to Manually Mount the Home Directory

If the directory for a user's home directory is located on another system and the Automounter is not being used to make that available, perform the following steps:

1. Log in as root on the user's system.

2. Edit the /etc/vfstab file, create an entry for the user's home directory, and save the file.

   For example, to create an entry for user ignatz, with a home directory on server venus, you add the following line:

venus:/export/home1/ignatz - /home/ignatz nfs - yes rw,intr

3. Type mkdir /home/username and press Return. This creates the mount point on the user's system where the remote home directory is mounted. Note that the home directory does not have the same name on the user's system as it does on the server. For example, /export/home/ignatz on the server would be mounted as /home/ignatz on the user's system. This step is not necessary when the home directory is mounted using the Automounter.

4. Type mountall and press Return.

   All entries in the current vfstab file (whose automnt fields are set to yes) are mounted.

5. To verify that all entries are mounted, type mount and press Return. The file systems that are mounted are displayed.

Customizing a User's Environment

Information You Need

• User's login name and password

· How to Customize a User's Environment

1. On the user's system, log in as the user.

   This step allows you to see the user's environment as he or she will see it.

2. Edit the user's initialization files.

   The following steps suggest some changes and show the shell-specific syntax to use. See step 3 for changes related to localization (for different locales or countries). However, you should minimize changes to the user's initialization file by putting as many of these kinds of changes as you can in the system initialization file on the systems in the network.

   a. Set the user's default path to include the home directory and directories or mount points for the user's windowing environment and applications.

   Do not use path names that are specific to a local system. Use global /net/machine-name/directory-name path names, so files can be mounted automatically on any system to which the user logs in. This capability requires that the auto_master file is set up properly on the network.

   To change the path setting, add or modify the line for PATH as follows:

   * For the Bourne or Korn shell, type

  PATH=.:/dirname1:/dirname2:/dirname3...; export PATH
  For example, enter a line like the following in the user's
  $HOME/.profile file:

PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin export PATH

The "dot" (.) at the beginning of the list means "current directory" and can be omitted if security is a concern.

* For the C shell, type

set path =(. /dirname1 /dirname2 /dirname3...)
For example, enter a line like the following in the user's
$HOME/.cshrc file:

set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)

The "dot" (.) at the beginning of the list means "current directory" and can be omitted if security is a concern.

b. Check that the environment variables are set to the correct directories or mount points for the user's windowing environments and third-party applications. Type env and press Return.

$ env HOME=/home/ignatz HZ=100 LOGNAME=ignatz MAIL=/var/mail/ignatz MANSECTS=\1:1m:1c:1f:1s:1b:2:\3:3c:3i:3n:3m:3k:3g:3e:3x11:3 xt:3w:3b:9:4:5:7:8 PATH=/usr/bin SHELL=/bin/sh TERM=sun TZ=EST5EDT $

c. Add or change the settings of environment variables by entering either of the following lines:

* For the Bourne or Korn shell, type VARIABLE=value;export VARIABLE The following line sets the user's default mail directory:

MAIL=/var/mail/iqnatz;export MAIL

* For the C shell, type setenv VARIABLE value The following line sets the history recorded to the last 100 commands:

setenv HISTORY 100

---

Note - For a user's home directory to be available anywhere on the network, refer to it with the variable $HOME. For example, use $HOME/bin; do not use /export/home/username/bin. $HOME works when the user logs in to another system, when home directories are automounted.

---

d. Check the umask setting to see if it is appropriate. If necessary, change it by typing umask nnn and press Return.

You can either include or omit leading zeros.

For example, to set file permissions to 644, type:

$ umask 022

Table 1-10 shows the file permissions that are created for each of the octal values of umask.

Table 1-10 umask

umask Octal Value	File Permissions
0	rwx
1	rw-
2	r-x
3	r--
4	-wx
5	-w-
6	--x
7	--- (none)

See "Default File Permissions (umask)" on page 41 for information about the umask command.

3. If necessary, configure the LANG variable and stty settings for different locales, as listed in Table 1-11.

   The LANG and LC environment variables determine which locale-specific conversions and conventions the shell will apply, like time zones, collation orders, and formats of dates, time, currency, and numbers. In addition, an stty setting determines whether the system will support multibyte characters.

a. Set the LANG and LC variables for the locale in the user's shell initialization file.

The default is the "C" locale. For the Bourne shell use the format: VARIABLE=value; export VARIABLE.

For the C shell use the format: setenv variable value.

Table 1-11 LANGLC

Value	Locale
de	German
fr	French
iso_8895_1	English and European
it	Italian
japanese	Japanese
korean	Korean
sv	Swedish
tchinese	Taiwanese

LANG sets all possible conversions and conventions for the given locale. If you have special needs, you can set various aspects of localization separately through these LC variables: LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_NUMERIC, LC_MONETARY, and LC_TIME.

b. If the system needs to support multibyte characters (for example, Japanese characters), add the following command to the system initialization file (/etc/profile or /etc/.login):

stty cs8 defeucw

To enable access to printers: After adding users to a system, you should make sure they have access to a printer. To set up a printer, see Chapter 3, "Setting Up Printers," for instructions. When printers are set up and running on the system or network, but one is not available, see "Making Printers Available" on page 103. If your site policy is to create an "allow" list for a printer so only users explicitly included in the list can use the printer, add the new user to the list as follows:

* Log in as root, type lpadmin -p printername -u allow:username and press Return.

To set up mail accounts: When the mail service is already running on the network, you can perform two tasks to add a new mail client to the network:

• Set up the mounting of a mailbox for the user (mail client) that will be mounted from a mail server.
• Add the user to existing mail aliases.

User Account Reference Information

Collect and Record User Information

You may find it useful to create a form like the one below to gather information about users. The items above the double line reflect the information specified when adding a user account with User Account Manager.

Item............Description

User Name:

UID:

Primary Group:

Secondary Groups:

Comment:

Default Shell:

Password Status and Aging:

Home Directory Server Name:

Home Directory Path Name:

Mounting Method:

Permissions on Home Directory:

Mail Server:

Department Name:

Department Administrator:

Manager:

Employee Name:

Employee Title:

Employee Status:.......Contract or Permanent

Employee Number:

Start Date:

Add to These Mail Aliases:

Desktop System Name:

Shell Features

Table 1-12 lists basic shell features, and shows which shells provide each feature.

Table 1-12

Feature	Bourne	C	Korn
Syntax compatible with sh	Yes	No	Yes
Job control	Yes	Yes	Yes
History list	No	Yes	Yes
Command-line editing	No	Yes	Yes
Aliases	No	Yes	Yes
Single-character abbreviation for login directory	No	Yes	Yes
Protect files from overwriting (noclobber)	No	Yes	Yes
Ignore CTRL-D (ignoreeof)	No	Yes	Yes
Enhanced cd	No	Yes	Yes
Initialization file separate from .profile	No	Yes	Yes
Logout file	No	Yes	No

Environment Variables and Shell Variables

The shell maintains an environment that includes a set of variables defined by the login program, the system initialization file, and the user's initialization files. In addition, some variables are defined by default. By definition, environment variables are variables exported to all processes spawned by the shell. Their settings can be seen with the env command. A subset of environment variables, like PATH, affects the behavior of the shell itself.

In the standard (Bourne or Korn) shell, environment variables are set with an assignment of NAME=value followed by an export NAME statement. In the C shell, the setenv NAME value statement both assigns the value and exports it to generated processes.

In addition to environment variables, the shell also maintains local or "shell variables" that affect only the current shell. In the C shell, a set of these shell variables have a special relationship to a corresponding set of environment variables. These shell variables are user, term, home, and path. The value of the environment variable counterpart is used initially to set the shell variable; when the shell variable is reset (with the set name = value statement), the environment variable counterpart is updated. In the C shell, you use the lowercase names to set these variables. In the Bourne and Korn shells, you use the uppercase names to set these variables and environment variables, in general. For all shells you refer to these variables and environment variables, in general, by the uppercase names.

You can customize the shell environment by changing the values of the predefined environment variables and by specifying additional environment variables. Environment variables can be stored in the system initialization file (/etc/profile and /etc/.login) or the user's $HOME/.profile, $HOME/.login, or $HOME/.cshrc file.

The following table describes some environment and shell variables you may want to customize either in the system initialization file or in a specific user's initialization files. For more information about variables used by the different shells, see sh(1), ksh(1), or csh(1).

Table 1-13 (1 of 3)

Shell Variable	Description
ARCH	Sets the user's system architecture (for example, sun4, i386). Set this variable with ARCH = `uname -p` (in Bourne or Korn shells) or setenv ARCH `uname -p` (in C shell). There is no built-in behavior of the shell that depends on this variable. It's just a useful variable for branching within shell scripts.
CALENDAR	Sets the path to the Calendar executables.
CDPATH (cdpath in the C shell)	Sets a variable used by the cd command. If the target directory of the cd command is specified as a relative path name, the cd command will first look for the target directory in the current directory ("."). If the target is not found, the path names listed in the CDPATH variable are searched consecutively until the target directory is found and the directory change is completed. If the target directory is not found, the current working directory is left unmodified. For example, the CDPATH variable is set to /home/jean, and two directories exist under /home/jean: bin and rje. If you are in the /home/jean/bin directory and type cd rje, you change directories to /home/jean/rje, even though you do not specify a full path
DESKSET	Sets the path to the DeskSet executables.
history	Sets history for the C shell.
HOME	(or home in the C shell)
LANG	Sets the locale.
LOGNAME	Defines the name of the user currently logged in. The default value of LOGNAME is automatically set by the login program to the user name specified in the passwd file. You should only need to reference (not reset) this variable.
LPDEST	Sets the user's default printer.
MAIL	Sets the path to the user's mailbox.
MANPATH	Sets the hierarchies of man pages available.

Table 1-13 (2 of 3)

Shell Variable	Description
MANSECTS	Sets the hierarchies of man pages available.
OPENWINHOME	Sets the path to the OpenWindows subsystem.
PATH (or path in the C shell)	Lists, in order, the directories that the shell searches to find the program to run when the user types a command. If the directory is not in the search path, users must type the complete path name of a command. The default PATH is automatically defined and set as specified in .profile (Bourne or Korn shell) or .cshrc (C shell) as part of the login process. The order of the search path is important. When identical commands exist in different locations, the first command found with that name is used. For example, suppose that PATH is defined (in Bourne and Korn shell syntax) as PATH=/bin:/usr/bin:/usr/sbin:$HOME/bin and a file named sample resides in both /usr/bin and /home/jean/bin. If the user types the command sample without specifying its full path name, the version found in /usr/bin is used.
prompt	Defines the shell prompt for the C shell.
PS1	Defines the shell prompt for the Bourne or Korn shell.
SHELL (or shell in the C shell)	Sets the default shell used by make, vi, and other tools.
TERMINFO	Specifies the path name for an unsupported terminal that has been added to the terminfo database. Use the TERMINFO variable in /etc/profile or /etc/.login. When the TERMINFO environment variable is set, the system first checks the TERMINFO path defined by the user. If it does not find a definition for a terminal in the TERMINFO directory defined by the user, it searches the default directory, /usr/share/lib/terminfo, for a definition. If it does not find a definition in either location, the terminal is identified as "dumb."
TERM (or term in the C shell)	Defines the terminal. This variable should be reset in /etc/profile or /etc/.login. When the user invokes an editor, the system looks for a file with the same name as the definition of this environment variable. The system searches the directory referenced by TERMINFO to determine the terminal characteristics.

Table 1-13 (3 of 3)

Shell Variable	Description
TZ	Sets the time zone, which is used to display dates, for example, in the ls -l command. If TZ is not set in the user's environment, the system setting is used; otherwise, Greenwich Mean Time is used.

Using the PATH Variable

When the user executes a command using the full path name, the shell finds the command using that path name. However, when users specify only a command name, the shell searches the directories for the command in the order specified by the PATH variable. If the command is found in one of the directories, the shell executes it.

A default PATH is set by the system, but most users modify it to add other command directories. Many user problems related to setting up the environment and accessing the right version of a command or a tool can be traced to incorrectly defined paths.

Here are some guidelines for setting up efficient PATH variables:

• If security is not a concern, put the current working directory (.) first in the path: PATH=.:/usr/bin for the Bourne and Korn shells; set path = (. /usr/bin) for the C shell. Including the current working directory in the path poses a security risk that you may want to avoid, especially for root. See Security, Performance, and Accounting Administration. The C shell updates the environment variable PATH when the shell variable path is reset.
• Keep the search path as short as possible. The shell searches each directory in the path. If a command is not found, long searches can slow down system performance.
• $PATH is read from left to right, so the most likely place to find a command should be at the beginning of the path.
• Make sure directories are not duplicated in the path.
• Avoid searching large directories, if possible. Put large directories at the end of the path.
• Put local directories before NFS-mounted directories to lessen the chance of "hanging" when the NFS server does not respond.

Default File Permissions (umask)

The default file permissions assigned when a file or directory is created are controlled by the user mask. The user mask is set by umask in either the .cshrc or the .profile initialization file (depending on the user's default shell). You can display the current value of the user mask by typing umask and pressing Return.

umask is set with a three-digit octal value. The first digit sets permissions for the user; the second sets permissions for group; the third sets permissions for other (also referred to as world). Note that if the first digit is zero, it is not displayed. For example, if umask is set to 022, 22 is displayed.

If umask is set to 000, each file created has permissions rw-rw-rw-(mode 666). Each directory created has default permissions rwxrwxrwx (mode 777). However, you can change umask value.

To determine the value you want to set, subtract the value of the permissions you want from 666 or 777. The remainder is the value to use for umask.

For example, suppose you want to change the default mode for files from 666 (rw-rw-rw-) to 644 (rw-r--r--). The difference, 022, is the value you use as an argument to umask command.

Message of the Day

The message of the day (MOTD) facility lets you send announcements or inquiries to all users of a system by adding the text of your message to the /etc/motd file. When users log in, the messages are displayed as part of the login process. Here is an example of a message of the day:

The system will be down from 1700 to 2300 hours on Friday, September 30, for upgrades and preventive maintenance.

Edit the /etc/motd file regularly to remove obsolete notices. Use the message of the day sparingly; if you inundate users with trivial messages, they will learn to ignore all your messages.