What Are User Accounts and Groups?
-
Guidelines for Assigning User Names, User IDs, and Group IDs
This section describes the following topics:
A typical user account includes the information a user needs to log in and use a system. 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 or 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 private that includes the users that are working on the non-public project. In addition, you could set up the private files with read permission for the private group so that only the users in the private group are able to read the files.
A special type of user account, called a role, gives special rights to specific users. For more information, see Chapter 1, About Using Rights to Control Users and Processes in Securing Users and Processes in Oracle Solaris 11.3.
User Account Components
This section describes the various components of a user account.
User (Login) Names
User names, also called login names, enable users to access their own local and remote systems that have the appropriate access rights. You must choose a unique user name for each 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, John Smith becomes jsmith. 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, John Jay Smith becomes jjsmith.
-
Using the first initial, middle initial, and first five characters of the user's last name
-
Adding the number 1, or 2, or 3, and so on, until you have a unique name
If this scheme still results in duplicate names, consider using the following scheme to create a user name:
Note - User names 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
A unique user identification number (UID) is associated with each user name. The UID number identifies the user name to any system on which the user attempts to log in. It is also used by systems to identify the owners of files and directories. If you create user accounts for an individual on a number of different systems, always use the same user name and ID number. This enables the user to 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.
|
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.
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, remove the account information completely so that the new user is not affected by attributes set for a former user. For example, a former user might have been included in a printer deny list. However, denying access to that printer 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.
|
UNIX Groups
A group is a collection of users who can share files and other system resources. For example, users working on the same project can 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.
-
Primary group – Specifies a group that the operating system assigns to files that are created by the user. Each user must belong to a primary group.
-
Secondary groups – Specifies one or more groups to which a user also belongs. Users can belong to up to 1024 supplemental groups.
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, the secondary group of a user is not important. For example, ownership of files reflect the primary group, not secondary groups. Other applications, however, might rely on the secondary group memberships of a user. For example, a user has to be a member of the sysadmin group (group 14) to use the Admintool software in previous Oracle 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, users can temporarily change their primary group to any other group in which the user is a member by using the newgrp command.
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 because 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.
-
Password length is defined by the value PASSLENGTH in the /etc/default/password file.
The default password hashing algorithm is SHA256. As a result, user passwords are no longer limited to eight characters as in previous Oracle Solaris releases. The eight-character limitation applies only to passwords that use the older crypt_unix (5) algorithm, which has been preserved for backward compatibility with any existing passwd file entries and NIS maps.
New passwords must match the complexity rules within the maximum number of characters that are allowed for the password algorithm. Thus, if you are using the crypt_unix algorithm and you type a 20-character password, the password must match the complexity rules within the first 8 characters. If the password algorithm is any of the other algorithms, the password must match the complexity rules within the full password that is entered, which is 20 in this example.
-
Each password must meet the configured complexity constraints that are specified in the /etc/default/passwd file.
-
Each password must not be a member of the configured dictionary as specified in the /etc/default/passwd file.
-
New passwords must not be present in the password history of the name service.
User passwords must comply with the following syntax:
Your password change policy should follow industry standards. System administration logins,such as root, must be carefully controlled. Administration should be through users with appropriate rights profiles, roles, or sudo. These administrative methods use least privilege and write administrative events to the audit trail. For password attributes that Oracle Solaris can enforce when a password is changed, see the passwd(1) man page.
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.
-
Phrases (beammeup).
-
Words made up of the first letters of every word in a phrase. For example, swotrb for SomeWhere Over The RainBow.
-
Words with numbers or symbols substituted for letters. For example, sn00py for snoopy.
Good choices for passwords include the following:
-
Your name (spelled forwards, backwards, or jumbled)
-
Names of family members or pets
-
Car license numbers
-
Telephone numbers
-
Social security numbers
-
Employee numbers
-
Words related to a hobby or interest
-
Seasonal themes, such as Santa in December
-
Any word in the dictionary
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 size of the system on which the directory is hosted, the kinds of files the user creates, the file size, and the number of files that are created.
A home directory can be located either on your 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 like /export/home/alice or /export/home/bob. By creating separate file systems for each user, you can set properties or attributes based on the needs of each user.
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 Autofs Administration in Managing Network File Systems in Oracle Solaris 11.3.
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. This is because the /export/home/username directory is system-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 irrespective of where the home directory is mounted.
For more information about how home directories are added when you create user accounts by using the command-line interface, 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 the /etc files of every system. 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 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 the work environment of users. These files reside locally on systems and are not centrally administered. For example, if AutoFS is used to mount the 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 About the User Work Environment.
Guidelines for Assigning User Names, User IDs, and Group IDs
User names, UIDs, and GIDs should be unique within your organization, especially if your setup involves multiple domains.
-
User names – Should contain from two to eight letters and numerals. The first character should be a letter. At least one character should be a lowercase letter.
Note - 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. -
System accounts – Do not use any of the user names, UIDs, or GIDs that are contained in the default /etc/passwd and /etc/group files. Do not use the UIDs and GIDs, 0-99. These numbers are reserved for allocation by Oracle Solaris and should not be used by anyone. Note that this restriction also applies to numbers not currently in use.
For example, gdm is the reserved user name and group name for the GNOME Display Manager daemon and should not be used for another user. For a complete listing of the default /etc/passwd and /etc/group entries, see Figure 3, Table 3, Default passwd File Entries and Figure 4, Table 4, Default group File Entries.
Caution - The nobody and nobody4 accounts should never be used for running processes. These two accounts are reserved for use by NFS. Use of these accounts for running processes could lead to unexpected security risks. Processes that need to run as non-root should use the daemon or noaccess accounts.
-
System account configuration – The configuration of the default system accounts should never be changed, including never changing the login shell of a system account that is currently locked. The only exception to this rule is the setting of a password and password aging parameters for the root account.
Note - Changing a password for a locked user account changes the password but no longer unlocks the account at the same time. A second step to unlock the account by using the passwd -u command is now required.
Keep the following guidelines in mind when creating user or role names, UIDs, and GIDs: