Managing User Accounts and Groups (Overview)
This chapter provides guidelines and planning information for managing user accounts and groups.This chapter also includes information about customizing the user's work environment.
This is a list of the overview information in this chapter.
For step-by-step instructions on managing user accounts and groups, see Chapter 5, Managing User Accounts and Groups (Tasks).
What's New in Managing Users and Groups?
This section describes new features for managing users and groups in the Solaris 9 release.
Solaris Management Console Tools Suite
The Solaris Management tools suite, available from the Solaris Management Console, enable you to manage all user and group features. For information on using the Solaris Management Console, see Chapter 2, Working With the Solaris Management Console (Tasks). For information on performing specific user and group management tasks, see "What You Can Do With Solaris User Management Tools".
Solaris Directory Services
You can manage user and group information in a LDAP (Lightweight Directory Access Protocol) directory service with the iPlanet™ Directory Server, as well as other LDAP directory servers. Managing user and group information is also available in the NIS, NIS+, or files environment.
For information on setting up LDAP, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
For information on managing users and groups with iPlanet Directory Server, see iPlanet Directory Server 5.1 Administrator's Guide at the http://docs.iplanet.com site.
Managing Users and Resources With Projects
In the Solaris 9 release, users and groups can be members of a project, an identifier that indicates a workload component that can be used as the basis of system usage or resource allocation chargeback. Projects are part of the Solaris resource management feature that is used to manage system resources.
Users need to be a member of a project to successfully log in to a system running the Solaris 9 release. By default, users are a member of the group.staff project when the Solaris 9 release is installed and no other project information is configured.
User project information is stored in the /etc/project file, which can be stored on the local system (files), the NIS name service, or the LDAP directory service. You can use the Solaris Management Console to manage project information.
The /etc/project file must exist for users to log in successfully, but requires no administration if you are not using projects.
For more information on using or setting up projects, see "Projects and Tasks" in System Administration Guide: Resource Management and Network Services.
What Are User Accounts and Groups?
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 information has the following components:
Also, when you set up a user account, you can add the user to predefined groups of users. A typical use of groups is to set up file and directory access only to users who are part of a group (using the group permissions on a file or directory).
For example, you might have a directory containing top secret files that only a few users should be able to access. You could set up a group called topsecret that include the users working on the topsecret project, and 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.
There is a special type of user account called a role, which is used to give selected users special privileges. For more information, see "Role-Based Access Control (Overview)" in System Administration Guide: Security Services.
A user or group can be a member of one or more projects. A project is an identifier that is used to chargeback system resources. For information on using projects, see "Projects and Tasks" in System Administration Guide: Resource Management and Network Services.
Guidelines for Managing User Accounts
The following sections describe some guidelines and planning information for creating user accounts.
Name 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, NIS, 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 using a name or directory service for user accounts, users can move from system to system using the same user account without having site-wide user account information duplicated on every system. Using a name or directory service also promotes centralized and consistent user account information.
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 you create. User (or role) names must:
Be unique within your organization, which might span multiple domains
Contain from two to eight letters and numerals (the first character should be a letter and at least one character should be a lowercase letter)
Even though user names can include a period (.), underscore (_), or hyphen (-), using these characters is not recommended because they can cause problems with some software products.
It is helpful to establish a standard way of forming user names, and the 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 that 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 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.
Note - Each new user name must be distinct from any mail aliases known to the system or to an NIS or NIS+ domain. Otherwise, mail might be delivered to the alias rather than to the actual user.
User ID Numbers
Associated with each user name is a user identification (UID) number. The UID number identifies the user name to any system on which the user attempts to log in, and it 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 user ID. In that way, the user can easily move files between systems without ownership problems.
UID numbers must be a whole number less than or equal to 2147483647. They are required for both regular user accounts and special system accounts. The following table lists the UID numbers reserved for user accounts and system accounts.
Table 4-1 Reserved UID Numbers
User ID Numbers | User/Login Accounts | Description |
|---|---|---|
0 - 99 | root, daemon, bin, sys, etc. | System accounts |
100 - 2147483647 | Regular users | General purpose accounts |
60001 and 65534 | nobody and nobody4 | Anonymous users |
60002 | noaccess | Non-trusted users |
Although UID numbers 0 through 99 are reserved, you can add a user with one of these numbers. However, do not 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.
As with user (login) names, you should adopt a scheme to assign unique UIDs. Some companies assign unique employee numbers, and 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 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, but that attribute might not be appropriate for the new user.