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/GIDs Over 60000
Category | Product/Command | Issues/Cautions |
|---|---|---|
NFS™ Interoperability | SunOS™ 4.0 NFS software and compatible versions | NFS server and client code truncates large UIDs and GIDs to 16 bits. This can create security problems if SunOS 4.0 and compatible machines are used in an environment where large UIDs and GIDs are being used. SunOS 4.0 and compatible systems require a patch. |
Name Service Interoperability | NIS name service and file-based name service | Users with UIDs above 60000 can log in or use the su command on systems running the Solaris 2.5 and compatible versions, but their UIDs and GIDs will be set to 60001 (nobody). |
| NIS+ name service | Users with UIDs above 60000 are denied access on systems running Solaris 2.5 and compatible versions and the NIS+ name service. |
Table 4-3 Large UID/GID Limitation Summary
UID or GID | Limitations |
|---|---|
60003 or greater |
|
65535 or greater |
|
100000 or greater |
|
262144 or greater |
|
1000000 or greater |
|
2097152 or greater |
|
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:
Phrases (beammeup)
Nonsense words made up of the first letters of every word in a phrase (swotrb for SomeWhere Over The RainBow)
Words with numbers or symbols substituted for letters (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. 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 become 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 and the type of work done.
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 "Autofs Administration Task Overview" in System Administration Guide: Resource Management and Network Services.
To use the home directory anywhere on the network, you should always refer to it 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 (.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 (/etc/profile, /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, then 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.