Managing User Accounts and User Environments in Oracle® Solaris 11.2

Exit Print View

Updated: September 2014
 
 

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.

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

  • 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 Table 1–3 and Table 1–4.


    Caution

    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.