Chapter 8: Adding a User
  1. Administration
  2. Making the User Known to the System
    1. The password file
      The group file
  3. Making the maps
  4. Creating the Home Directory
  5. Final points
  6. Restricting Access to Hosts
    1. Adding restricted users
  7. NIS and the Local /etc/passwd file
    1. Denying access to the Few
      /etc/passwd on a mailhub
      The shadow passwd file
This method assumes that there are no restrictions on access to all the hosts in the NIS domain and that the user's home directory will be on an existing disk.


1. Have the user fill in an application form and make sure they get the appropriate permissions to use hosts and disk space.

2. Assign a username, UID, GID and home directory to the user.

Check first in the CURD using lookup ( see man lookup for details) that this username does not already exist. Each NERC site has been assigned a range of UIDs and GIDs for their exclusive use; this list is shown in Appendix 1. Note: The UIDs are unique, you cannot use the same UID with different GIDs. If a user is from another site, he should have a UID,GID allocated by that site. An individual should have the same UID,GID on all UNIX systems anywhere in NERC. New usernames should NOT have an underscore prefix, as was used on NCS VAXes.

3. Register the user in the CURD: mail with the user's full name, site name,id, UID and GID.  Only one person on a site should do this, otherwise the CURD administrator may refuse to add the ID.

Back to contents

Making the User Known to the System

The password file

4. Logon to the NIS master and become root.

5. Edit the /nerc/<domain>/yp/passwd file to include the new username (id). Note that the active passwd file is not changed until 'make' has been run, so mistakes are not catastrophic. It is essential that each entry in the password file has exactly 7 fields - failure to do this can have strange side effects such as causing sendmail to go mad. Use pwck to check the passwd file for syntax errors; it will complain that no login directory exists for the entry you have just put in.

At this point leave the password field empty, the password will be set later. All users will have a (logical) login directory in the form

/users/[<group>]/<id> ( which form depends on local custom). The passwd file entry will be:



dr::1234:1000:David Ritchie, NCS:/users/ncs/dr:/bin/csh


alone::1256:1090:John Doe :/users/alone:/bin/csh

/nerc/<domain>/yp/passwd is the 'master' passwd file and is used to register ALL user ids for the NIS domain. All hosts will access the NIS database created from this file, during login for example, to resolve userid details according to entries in their own local /etc/passwd files (see Restricting Access To Hosts.)

The group file

6. Edit the /nerc/<domain>/yp/group file to include the user's GID if it is new. /nerc/<domain>/yp/group is the 'master' group file and is used to register ALL group ids for the NIS domain. All hosts will access the NIS database created from this file, during login for example, to resolve group details. Use grpck to check the group file for syntax errors.

Back to contents


7.Edit the /nerc/<domain>/yp/auto.users file if necessary. If the user is a member of an existing group and their home directory has to be created under an existing /local[n]/users/<group> directory then there should already be an entry in auto.users to do the appropriate translation in the form...

<group> <host>:/local[n]/users/<group>


ncs kwde:/local/users/ncs

This entry means that any directory reference beginning /users/ncs will cause the automounter to do the appropriate NFS mount of the physical directory /local/users/ncs from kwde. Once mounted, all of /local/users/ncs's subdirectories become 'visible' therefore dr and all other NCS group users' login directories can be accessed if permission allows (via /users/ncs/<id>).

If on the other hand you have users' login directories randomly spread among your disks then an explicit entry will be used for each user in the form...

<id> <host>:/local[n]/users/<id>


alone kwdx:/local2/users/alone

This map is consulted by the automount daemon on every host in the NIS domain and is, in essence, the translation table between logical user home directories /users/... (which can be used on any host) and the physical host and directory <host>:/local[n]/users/... .

Note: The auto.users map is indirect therefore additions come into effect as soon as the map has been 'made' into a NIS database and distributed to the rest of the NIS domain.  It is not necessary to restart any automount daemons.

Back to contents

Making the maps

8. Create and distribute (push) the new NIS databases for passwd, group and auto.users...

# cd /var/yp

# ./make or (./ypmake on SG)

You should see something like...

updated passwd

pushed passwd

updated group

pushed group

updated auto.users

pushed auto.users


Creating the Home Directory

9. Now that the new user's id is activated, by 'making' the master NIS passwd (and group) file, we can create the user's login directory and give them the standard .cshrc, .login and .logout files

Login to the host with the physical disk attached which will hold the new user's login directory and become root.

# cd /local[n]/users

# umask 22 for drwxr-xr-x on new directory

If this is a new group:

[# mkdir <group>] Create the group directory if necessary

[# cd <group>]

If the group already exists:

# cd /local/users/<group>

# umask 22 drwxr-xr-x on directory

# mkdir <id>

# cp /nerc/scripts/newuser/.* <id>/ Copies standard .cshrc etc. to user's directory

# chown -R <id>.<group> <id> Recursively change ownership of all new files ( this works on SunOS and IRIX, for Solaris use chown -R <id> followed by chgrp -R <group> )

NOTE: if a script exists at your site which does the above sequence of operations, use it, to reduce the chance of errors.

Back to contents

For a 'personal' directory:

# cd /local2/users

# umask 22 (Necessary for SG or Solaris printing)

# mkdir alone

# cp /nerc/scripts/newuser/.* alone/

# chown -R alone.1090 alone

Note: the gid may be used instead of the group name, as shown here. (For Solaris use chown -R alone; chgrp -R 1090 )

Final points

10. At this point anyone can login to the new id because there is no password set, therefore login as the user and set a password. It's not the neatest way of doing it but it is guaranteed to work and has the virtue of checking unequivocally that the user will be able to login!  On most sites the chpasswd utility is now available; this checks new passwords for complexity and will not accept easily-guessable ones.

Note that setting world read and execute permissions on the user home directory is necessary if any files are to be visible from another system, such as his mail .forward file. Often the mailhub is not the same system as that serving user home directories. Assuming he removes world read permission from all his files and lower-level directories, these will be just as secure as if he had not had world read and exeucte on his top directory.

11. Give the new user details of his id. Normally this is the end of the process of adding a user.

Back to contents

Restricting Access To Hosts

Situations will arise where certain hosts in a NIS domain are out of bounds to the general user, such as database servers or project machines. The instructions for this are given below, and a fuller discussion of the details is at the end of the chapter.

Adding Restricted Users

There are a couple of extra steps involved in adding restricted users

12. An id does not have to have access to the host which holds their physical login directory. If this is the case then the ownership of the login directory files would be defined in terms of UID and group rather than username and group. This is because the username is not valid for that host, therefore it cannot translate the username into the UID which is what the operating system actually uses for file ownership. There has been no real reason not to use the NIS wildcard in the local /etc/group file therefore the GID or the group name can be used.

13. Give the user access to the appropriate hosts by adding the NIS entry to the host's /etc/passwd file in the form...



Login to the host and become root.

# cd /etc

# vipw Vipw, if available, should be used to edit the /etc/passwd file, and add


at the end.
14. If this is a Solaris system, run pwconv after editing the password file, to update the shadow password file ( see below).


15. Login as the user on the restricted host ( to check that he has access) and change his password.

  NOTE: There was a certain release of Solaris 2.3 where this +<id> device not only didn't work, it prevented anyone except root from logging on. If this is the first entry of this kind, check with Systems Group that it will work!

Back to contents

NIS And The Local /etc/passwd File

As hosts join a NIS domain one of the things the system administrator (or the installation itself) will do is put the NIS wildcard as the last line of the host's /etc/passwd file. The wildcard allows anyone registered in the NIS master passwd database to login and use that host's CPU. The automount daemon will take care of finding and NFS mounting the user's login directory.

The NIS recommended wildcard can vary from architecture to architecture but the safest common denominator is +::0:0:::. This tells the operating system that if a userid is not found in the host's own /etc/passwd file then continue the search through the NIS master passwd database.

ANOTHER NOTE: Be warned! The /etc/passwd entry for root under Solaris has /bin/sh for its shell. DO NOT CHANGE THIS! If you want root to have /bin/csh as its default shell add another user called rootcsh as an exact copy of the root entry, but with /bin/csh.

Denying access to the few

If the majority of registered users can use a host then access can be denied to the few using the following NIS syntax in conjunction with the NIS wildcard...






Back to contents

/etc/passwd on a mailhub

For a host which is a mailhub but which for some reason has restricted access to users, we use the following technique:

Last few lines of /etc/passwd file on the mailhub:




The final entry means recognise all the entries from the NIS passwd file but don't let any of them log in, other than the ones mentioned above, i.e. the dummy password field (*) overrides the real password in the NIS passwd map and prohibits logins.

More complicated control over access can be found in NIS documentation or man 5 passwd on Suns and man 4 passwd on Silicon Graphics.

The shadow passwd file

Under Solaris 2, the password field /etc/passwd contains an "x" character. This simply says that the real password field is in another file called /etc/shadow. which, unlike /etc/passwd, is not world-readable. The two files are kept in step by the pwconv program - edit /etc/passwd, then run pwconv. Don't remove world read permission from /etc/passwd - all sorts of unfortunate effects follow from this.

Back to contents

This page last updated February 18th 1998 by