About User Accounts and Groups
A user account includes the information a user needs to log in and use a system. The following sections describe components of user accounts.
A role is a special type of user account that grants special rights to specific users. For more information, see About Using Rights to Control Users and Processes in Securing Users and Processes in Oracle Solaris 11.4.
All security policy configurations for user account attributes are provided by the SMF service account-policy. In previous Oracle Solaris releases, these were defined in individual configuration files such as /etc/default/login or /etc/security/policy.conf. For information about configuring security policies through the account-policy SMF service, see Modifying Rights System-Wide As SMF Properties in Securing Users and Processes in Oracle Solaris 11.4 as well as the account-policy(8S) man page.
User Account Components
The following sections describe components of a user account.
User Names
Users access local or remote systems through their user or login names. The extent of access depends on the user's rights.
Before you create accounts, plan on a standard way of assigning user names that facilitates tracking them and associating them with actual persons. With the standard as foundation, you only need to make slight adjustments for contingencies. For example, if your standard is based on users' first initials and surnames, you can easily adjust if two users share the same first initial and last names.
User ID Numbers
Each user name is associated with a unique user identification number (UID). A UID can be any whole number up to 2147483647.
Systems use the UIDs to identify users who are logging in as well as owners of files and directories. For ease of management, an individual with accounts on different systems should use the same user name and UID. UIDs are required for both regular user accounts and special system accounts.
UNIX™ Groups
A group, also known as a UNIX group, is a collection of users who can share files and other system resources, such as users who are working on the same project.
Users are added to groups. Permissions granted to groups control the types of access that members have to files or directories.
Each group must have a name and a group identification (GID) number. The GID identifies the group internally to the system.
- Primary group – automatically created by the operating system. The group is given access rights to specific files, including those that are created by the user. Each user must belong to a primary group. By default, a new user is added to the
staffgroup (GID 10). - Secondary group – manually created to which users are added as members. Users can belong to up to 1024 supplemental groups.
The priority of secondary groups vary. For example, file ownership requires membership in a primary group. But other applications might rely on a user's belonging to a secondary group regardless of the user's primary group.
Groups can be local to a system or managed through a name service. To simplify group administration, use the LDAP directory service to centrally manage group memberships.
User Passwords
You can specify the password for a new user or force the user to specify a unique password at the user's initial login.
By default, the minimum password length is set to 8 bytes by the PASSLENGTH parameter of the /etc/default/passwd file. This file includes other configurable parameters that together form the password policy that is enforced at your site.
Policies surrounding password creation and changes must implement the strictest security standards possible such as use of special characters, restricting the reuse of old passwords, case sensitivity, allowing longer passwords, and so on. These practices help prevent password theft and consequent security breaches.
For additional password attributes, see the passwd(1) man page.
Oracle Solaris has other security features other than passwords. Refer to the Securing the Oracle Solaris Operating System shelf in https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/.
Home Directories
The home directory is the portion of a file system that is allocated to a user for storing private files. You determine the amount of space to allocate for home directories.
A home directory can be either on the local system or on a remote file system. By convention the home directory should be created as /export/home/username. For a large site, you should store home directories on a server.
Regardless of the home directory location, users usually access their home directories through a mount point named /home/username.
If AutoFS is used to mount home directories, the home mount point acquires a special status. Thus, you cannot create any directories on that mountpoint on any system. For more information about auto-mounting home directories, see Autofs Administration in Managing Network File Systems in Oracle Solaris 11.4.
Guidelines for Assigning User Names, UIDs, and GIDs
- User names – Should be unique within your organization. For acceptable formats of user names, refer to passwd(5).
- System accounts – Observe the restrictions on the use of certain UIDs and GIDs regardless of their being in actual use. For guidance, refer to Reserved UIDs.
Never use the
nobodyandnobody4accounts for running processes. These accounts are reserved for use by NFS. Use of these accounts for running processes can lead to unexpected security risks. Processes that need to run as non-root should use thedaemonornoaccessaccounts. - System account configuration – Never change the configuration of the default system accounts, including 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
rootaccount.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 -ucommand is now required.
The next sections further describe limitations to observe when assigning UIDs and GIDs.
Reserved UIDs
The following table lists the UID ranges that are assigned to user 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 |
Network File System (NFS) Anonymous users |
| 60002 | noaccess |
Reserved for operating system (OS) |
Of the UIDs reserved for the OS, root typically has 0, daemon 1, and pseudo-user bin 2.
As with user names, adopt a scheme for assigning unique UID numbers. For example, some companies assign unique employee numbers. Then, administrators add a number to the employee number to create a unique UID for each employee.
To minimize security risks, avoid reusing 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 previous user.
User ID and Group ID Maximum Values
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. The UIDs and GIDs are set to nobody in the archive.
|
| 2097152 or greater | Users who use the cpio -H odc or the pax -x cpio commands to copy files see an error message returned for each file. 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, the cpio -H ustar command, or the pax -x tar commands have their UIDs and GIDs set to nobody.
|