Previous Table of Contents Next


Disabling User Accounts

Occasionally, you may need to temporarily or permanently disable a login account. You should have good reason for taking such action. For example, the user may be on leave of absence or you may have strong evidence that the account is being misused or security is being violated.

The easiest way to disable a login account is to lock the password for an account. To lock the password on a local system, modify the user account and choose Account is Locked from the Password menu in the Admintool: Modify User window, as shown in Figure 7-9.


Figure 7-9  The Admintool:Modify User Password menu.

On a local system, you can control access to a user's account by requiring password aging, by setting an expiration date for the login account, or by requiring that a user access the account at regular intervals. Another way that you can disable a login is to temporarily change the password.

Setting Up and Administering Groups

The Group database (map, or local /etc/group file) stores information about user groups, traditionally called UNIX groups. A user group is a collection of users who can share files and other system resources. For example, a set of users who are working on the same project could be formed into a user group.

Each group has a GID, 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:

  Implicitly, by the GID for the user's primary group, which is defined in the user account. Whenever a new GID appears in the Group field of the Passwd database, a new group is defined.
  Explicitly, by name, GID, and user list, as entered into the Group database.


NOTE:  It's best to explicitly define all groups so every group has a name.

All users belong to at least one group--their primary group--which is indicated by the Group field of their user account. Although it is not required by the operating system, you should add the user to the member list of the group you've designated as his or her primary group. Optionally, users can belong to up to 16 secondary groups. To belong to a secondary group, the user must be added to the group's member list.

The groups command shows the groups to which a user belongs. For any user, only one group can be considered the primary group at a time. However, users can temporarily change the primary group (with the newgrp command) to any other group they belong to.

Some applications, such as the file system, look at the user's primary group only. For example, ownership of files created, and recorded accounting data reflect only the primary group. Other applications may take into account a user's membership across groups. For example, a user has to be a member of the sysadmin group to use Admintool to make changes to a database, but it doesn't matter if sysadmin is the 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 other on files and directories. These permissions are a cornerstone of security. You cannot access others' files (if they do not allow world access) unless your primary or a 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 workstation 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 workstation or file server without making those files available to everyone.


NOTE:  NIS+ supports another, unrelated, kind of group, called NIS+ group, which assigns access rights to NIS+ objects. These groups have nothing to do with using NIS+ to maintain a database of user groups.

Setting Up Fields in the Group Database

The Group database (map, or local /etc/group file) has these fields:

  Group Name
  Group ID
  User (Member) List

There is an additional field that rarely is used: the 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.

Setting Up a Group Name Field

The Group Name field 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.

Setting Up a Group ID Field

The Group ID field contains the group's numerical ID. It must be unique from all other group IDs on a system and should be unique across the entire organization. Each GID must be a whole number between 0 and 60002, but customarily you use numbers from 100 to 60000. (Numbers 60001 and 60002 are assigned to nobody and noaccess, respectively, and numbers under 100 are reserved for system default group accounts.) When you use Admintool to add user accounts, you must specify the user's primary group; otherwise, the default primary group is root with a GID of 0. For security reasons, you do not want users to have a group of root.

Starting with the Solaris 2.5.1 release, you can also assign GID numbers between 6003 and 2147483647. If you use GID numbers in this range, refer to Table 7-4 and Table 7-5 for information about interoperability issues and limitations on large GID numbers.

Setting Up a User (Member) List Field

The User List field contains a list of the users in the group. User names are separated by commas. These names must be the official login names defined in the Passwd database. As already noted, each user can belong to a maximum of 17 groups.


Previous Table of Contents Next