JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Managing User Accounts and User Environments in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Managing User Accounts and User Environments (Overview)

What's New or Changed in Managing User Accounts and User Environments?

Security Changes That Impact User Account Management

Introducing the User Manager GUI

Administrative Editor (pfedit)

/var/user/$USER Subdirectory

groupadd Command Changes

Failed Login Count Notification

What Are User Accounts and Groups?

User Account Components

User (Login) Names

User ID Numbers

Using Large User IDs and Group IDs

UNIX Groups

User Passwords

Home Directories

Naming Services

User's Work Environment

Guidelines for Assigning User Names, User IDs, and Group IDs

Where User Account and Group Information Is Stored

Fields in the passwd File

Default passwd File

Fields in the shadow File

Fields in the group File

Default group File

Commands for Obtaining User Account Information

Commands That Are Used for Managing Users, Roles, and Groups

Customizing a User's Work Environment

Using Site Initialization Files

Avoiding Local System References

Shell Features

Bash and ksh93 Shell History

Bash and ksh93 Shell Environment Variables

Customizing the Bash Shell

MANPATH Environment Variable

PATH Environment Variable

Setting Path Guidelines

Locale Variables

Default File Permissions (umask)

Customizing a User Initialization File

2.  Managing User Accounts by Using the Command-Line Interface (Tasks)

3.  Managing User Accounts by Using the User Manager GUI (Tasks)

Index

What Are User Accounts and Groups?

The following information is described in this section:

One basic system administration task is to set up a user account for each user at a site. A typical user account includes the information a user needs to log in and use a system, without having the system's root password. User account components are described in User Account Components.

When you set up a user account, you can add the user to a predefined group of users. A typical use of groups is to set up group permissions on a file and directory, which allows access only to those users who are part of that group.

For example, you might have a directory containing confidential files that only a few users should be able to access. You could set up a group called topsecret that includes the users that are working on the topsecret project. In addition, you could set up the topsecret files with read permission for the topsecret group. That way, only the users in the topsecret group would be able to read the files.

A special type of user account, called a role, gives selected users special privileges. For more information, see Role-Based Access Control (Overview) in Oracle Solaris 11.1 Administration: Security Services.

User Account Components

The following sections describe the various components of a user account.

User (Login) Names

User names, also called login names, let users access their own systems and remote systems that have the appropriate access privileges. You must choose a user name for each user account that you create.

Consider establishing a standard way of assigning user names so that they are easier for you to track. Also, names should be easy for users to remember. A simple scheme when selecting a user name is to use the first name initial and first seven letters of the user's last name. For example, Ziggy Ignatz becomes zignatz. If this scheme 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 this scheme still results in duplicate names, consider using the following scheme to create a user name:


Note - Each new user name must be distinct from any mail aliases that are known to the system or to a NIS domain. Otherwise, mail might be delivered to the alias rather than to the actual user.


For detailed guidelines on setting up user (login) names, see Guidelines for Assigning User Names, User IDs, and Group IDs.

User ID Numbers

Associated with each user name is a user identification number (UID). The UID number identifies the user name to any system on which the user attempts to log in. And, the UID number is used by systems to identify the owners of files and directories. If you create user accounts for a single individual on a number of different systems, always use the same user name and ID number. In that way, the user can easily move files between systems without ownership problems.

UID numbers must be a whole number that is less than or equal to 2147483647. UID numbers are required for both regular user accounts and special system accounts. The following table lists the UID numbers that are reserved for user accounts and system accounts.

Table 1-1 Reserved UID Numbers

UID Numbers
User or Login Accounts
Description
0 – 99
root, daemon, bin, sys, and so on
Reserved for use by the operating system
100 – 2147483647
Regular users
General purpose accounts
60001 and 65534
nobody and nobody4
NFS Anonymous users
60002
noaccess
Non-trusted users

Do not assign UIDs 0 through 99. These UIDs are reserved for allocation by Oracle Solaris. 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, such as who, tty, and ttytype, low UIDs so that they fall at the beginning of the passwd file.

For additional guidelines on setting up UIDs, see Guidelines for Assigning User Names, User IDs, and Group IDs.

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

To minimize security risks, you should avoid reusing the UIDs from deleted accounts. If you must reuse a UID, “wipe the slate clean” so that the new user is not affected by attributes set for a former user. For example, a former user might have been denied access to a printer by being included in a printer deny list. However, that attribute might be inappropriate for the new user.

Using Large User IDs and Group IDs

UIDs and group IDs (GIDs) can be assigned up to the maximum value of a signed integer, or 2147483647.

The following table describes UID and GID limitations.

Table 1-2 Large UID and GID Limitation Summary

UID or GID
Limitations
262144 or greater
Users who use the cpio command with the default archive format to copy a file see an error message for each file. And, the UIDs and GIDs are set to nobody in the archive.
2097152 or greater
Users who use the cpio command with the -H odc format or the pax -x cpio command to copy files see an error message returned for each file. And, the UIDs and GIDs are set to nobody in the archive.
1000000 or greater
Users who use the ar command have their UIDs and GIDs set to nobody in the archive.
2097152 or greater
Users who use the tar command, the cpio -H ustar command, or the pax -x tar command have their UIDs and GIDs set to nobody.

UNIX Groups

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

Each group must have a name, a group identification (GID) number, and a list of user names that belong to the group. A GID number identifies the group internally to the system.

The two types of groups that a user can belong to are as follows:

For detailed guidelines on setting up group names, see Guidelines for Assigning User Names, User IDs, and Group IDs.

Sometimes, a user's secondary group is not important. For example, ownership of files reflect the primary group, not any secondary groups. Other applications, however, might rely on a user's secondary group memberships. For example, a user has to be a member of the sysadmin group (group 14) to use the Admintool software in previous Solaris releases. However, it does not matter if group 14 is the user's current primary group.

The groups command lists the groups that a user belongs to. A user can have only one primary group at a time. However, a user can temporarily change the user's primary group, with the newgrp command, to any other group in which the user is a member.

When adding a user account, you must assign a primary group for a user or accept the default group, staff (group 10). The primary group should already exist. If the primary group does not exist, specify the group by a GID number. User names are not added to primary groups. If user names were added to primary groups, the list might become too long. Before you can assign users to a new secondary group, you must create the group and assign it a GID number.

Groups can be local to a system or managed through a name service. To simplify group administration, you should use a name service such as NIS or a directory service such as LDAP. These services enable you to centrally manage group memberships.

User Passwords

You can specify a password for a user when you add the user. Or, you can force the user to specify a password when the user first logs in to the system. Although user names are publicly known, passwords must be kept secret and known only to users. Each user account should be assigned a password.

User passwords must comply with the following syntax:

Password rules are explained in detail in the passwd(1) man page.

To make your computer systems more secure, users should change their passwords periodically. For a high level of security, you should require users to change their passwords every six weeks. Once every three months is adequate for lower levels of security. System administration logins (such as root and sys) should be changed monthly, or whenever a person who knows the root password leaves the company or is reassigned.

Many breaches of computer security involve guessing a legitimate user's password. You should make sure that users avoid using proper nouns, names, login names, and other passwords that a person might guess just by knowing something about the user.

Good choices for passwords include the following:

Do not use these choices for passwords:

Home Directories

The home directory is the portion of a file system that is 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, their size, and the number of files that are created.

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 should be created as /export/home/username. For a large site, you should store home directories on a server. Use a separate file system for each user. For example, /export/home/alice or /export/home/bob. By creating separate file systems for each user, you can set properties or attributes based on each user's needs.

Regardless of where their home directory is located, users usually access their home directories through a mount point named, /home/username. When AutoFS 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 AutoFS is active. For more information about auto-mounting home directories, see Task Overview for Autofs Administration in Managing Network File Systems in Oracle Solaris 11.1.

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

For more information about how home directories are added when you create user accounts by using the CLI, see Guidelines for Setting Up User Accounts.

Naming Services

If you are managing user accounts for a large site, you might want to consider using a name or directory service such as LDAP, or NIS. A name or directory service enables you to store user account information in a centralized manner instead of storing user account information in every system's /etc files. When you use a name service or a directory service for user accounts, users can move from system to system using the same user account, without having their information duplicated on every system. Using a naming service or a directory service also ensures consistent user account information.

User's Work Environment

Besides having a home directory to create and store files, users need an environment that gives them access to the tools and resources they need to do their work. When a user logs in to a system, the user's work environment is determined by initialization files. These files are defined by the user's startup shell, which can vary, depending on the release.

A good strategy for managing the user's work environment is to provide customized user initialization files, such as .bash_profile, .bash_login, .kshrc, or .profile, in the user's home directory.


Note - Do not use system initialization files, such as /etc/profile or /etc/.login, to manage a user's work environment. These files reside locally on systems and are not centrally administered. For example, if AutoFS is used to mount the user's home directory from any system on the network, you would have to modify the system initialization files on each system to ensure a consistent environment whenever a user moved from system to system.


For detailed information about customizing user initialization files for users, see Customizing a User's Work Environment.

For information about how to customize user accounts through the RBAC, see Role-Based Access Control (Overview) in Oracle Solaris 11.1 Administration: Security Services for more information.

Guidelines for Assigning User Names, User IDs, and Group IDs

User names, UIDs, and GIDs should be unique within your organization, which could span multiple domains.

Keep the following guidelines in mind when creating user or role names, UIDs, and GIDs: