A role is a special type of user account that grants 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.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.
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.
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.
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.
A user can belong to two types of groups:
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 staff group (GID 10).
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.
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, password length is set to 8 bytes in the PASSLENGTH parameter of the /etc/default/passwd file. The file contains 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/cd/E37838_01/.
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.
Oracle Solaris 11.4 uses LDAP as its directory service. The directory service enables you to store user account information in a centralized manner. The service provides ease of connections to different systems and also ensures consistent user account information.
Keep the following guidelines in mind when creating user or role 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 Figure 1, Table 1, Reserved UID Numbers.
Never use the nobody and nobody4 accounts 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 the daemon or noaccess accounts.
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 root account.
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.
The next sections further describe limitations to observe when assigning UIDs and GIDs.
The following table lists the UID ranges that are assigned to user and system accounts.
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.
The following table describes UID and GID limitations.