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.
Keep the following guidelines in mind when creating user or role names:
-
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.
Consider establishing a standard way of assigning user names so 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, Ziggy Ignatz becomes zignatz. 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, Ziggy Top Ignatz becomes ztignatz. If this scheme still results in duplicate names, consider using the following scheme:
-
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 user UID identifies the user name to any system on which the user attempts to log in. And, the user UID 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. UID numbers 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 |
Use or Login Accounts |
Description |
|---|---|---|
|
0 - 99 |
root, daemon, bin, sys, and so on. |
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 0 through 99 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.
Using Large User IDs and Group IDs
UIDs and GIDs can be assigned up to the maximum value of a signed integer, or 2147483647.
However, UIDs and GIDs over 60000 do not have full functionality and are incompatible with many Solaris features, so avoid using UIDs or GIDs over 60000.
The following table describes interoperability issues with Solaris products and previous Solaris releases.
Table 4–2 Interoperability Issues for UIDs or GIDs Over 60000|
Category |
Product or Command |
Issues or Cautions |
|---|---|---|
|
NFSTM Interoperability |
SunOSTM 4.0 NFS software and compatible releases |
NFS server and client code truncates large UIDs and GIDs to 16 bits. This situation can create security problems if systems running SunOS 4.0 and compatible releases are used in an environment where large UIDs and GIDs are being used. Systems running SunOS 4.0 and compatible releases require a patch to avoid this problem. |
|
Name Service Interoperability |
NIS name service and file-based name service |
Users with UIDs greater than 60000 can log in or use the su command on systems running the Solaris 2.5 and compatible releases, but their UIDs and GIDs will be set to 60001 (nobody). |
|
|
NIS+ name service |
Users with UIDs greater than 60000 are denied access on systems running Solaris 2.5 and compatible releases and the NIS+ name service. |
Table 4–3 Large UID or GID Limitation Summary
Passwords
Although user names are publicly known, passwords must be kept secret and known only to users. Each user account should be assigned a password, which is a combination of six to eight letters, numbers, or special characters. You can set a user's password when you create the user account and have the user change it when logging in to a system for the first time.
To make your computer systems more secure, ask users to change their passwords periodically. For a high level of security, you should require users to change their passwords every six weeks. Once every three months is adequate for lower levels of security. System administration logins (such as root and sys) should be changed monthly, or whenever a person who knows the root password leaves the company or is reassigned.
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.
Good choices for passwords include the following:
-
Phrases (beammeup)
-
Nonsense 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.
Do not use these choices for passwords:
-
Your name, forwards, backwards, or jumbled
-
Names of family members or pets
-
Car license numbers
-
Telephone numbers
-
Social Security numbers
-
Employee numbers
-
Names related to a hobby or interest
-
Seasonal themes, such as Santa in December
-
Any word in the dictionary
Password Aging
If you are using NIS+ or the /etc files to store user account information, you can set up password aging on a user's password. Starting in the Solaris 9 Update 2 release, password aging is also supported in the LDAP directory service.
Password aging enables you to force users to change their passwords periodically or to prevent a user from changing a password before a specified interval. If you want to prevent an intruder from gaining undetected access to the system by using an old and inactive account, you can also set a password expiration date when the account becomes disabled. You can set password aging attributes with the passwd command or the Solaris Management Console's Users Tool.
Home Directories
The home directory is the portion of a file system allocated to a user for storing private files. The amount of space you allocate for a home directory depends on the kinds of files the user creates, large or small, and the number of files created.
A home directory can be located either on the user's 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 /export/homen directory to facilitate backing up and restoring home directories. For example, /export/home1, /export/home2.
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 automounting home directories, see “Task Overview for Autofs Administration” in System Administration Guide: Resource Management and Network Services.
To use the home directory anywhere on the network, you should always refer to the home directory as $HOME, not as /export/home/username. The latter is machine-specific. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x), so the links will be valid no matter where the home directory is mounted.
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 that are defined by the user's startup shell, such as the C, Korn, or Bourne shell.
A good strategy for managing the user's work environment is to provide customized user initialization files, such as .login, .cshrc, .profile, in the user's home directory. For detailed information about customizing user initialization files for users, see Customizing a User's Work Environment. After you create the customized user initialization files, you can add them to a user's home directory when you create a new user account.
A recommended one-time task is to set up skeleton directories on a server. You can use the same server where the user's home directories are stored. The skeleton directories enable you to store customized user initialization files for different types of users.
Note –
Do not use system initialization files, such as /etc/profile or /etc/.login, to manage a user's work environment, because they reside locally on systems and are not centrally administered. For example, if AutoFS is used to mount the user's 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 when a user moved from system to system.
Another way to customize user accounts is through role-based access control. See “Role-Based Access Control (Overview)” in System Administration Guide: Security Services for more information.
- © 2010, Oracle Corporation and/or its affiliates