|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 5: Account Management |
|
||||||||||||||||||||||||||||||||||||
|
There are different ways that accounts can be set up: through a graphical user interface (GUI), from scripts and programs, or manually from scratch.
Platform: AT&T, some BSD
Some systems enable you to create user accounts from within a GUI. The graphical tools are usually designed to consider any possible condition that the user or administrator might attempt. User accounts are not created if any one of the rules is not met.
These rules apply to the seven simple fields of the password file that all UNIX administrators should know. They test for the uniqueness of the account name, UID, and home directories. They look for a valid GID, shell, and, depending on the level of security in your environment, a permanent password or temporary password that cannot be cracked. Prompts for information regarding the user's account, who they are, where they are located, and numbers to reach them are provided by these tools.
There are additional features these tools use to make administration easier, such as adding quotas and password aging to accounts. They handle password shadowing and can generate valid unique UIDs and home directories on-the-fly. User accounts can be created, modified and deleted in under a minute. Another nice feature that appears on some of these interfaces is logging of all actions that take place. If something was done without your approval, you can backtrack to see what was done last, and sometimes by who.
These tools are available on various flavors of UNIX (and might go by different names):
AIX--smit (System Management Interface Tool) can run with or without graphics--it has a proprietary ASCII interface.
HP-UX--sam (System Admin Tool) has a graphical interface, but can run in an ASCII mode. This is a HP proprietary interface.
Solaris--admintool (Administration Tool) has no ASCII interface and runs only from a GUI. This is a Sun proprietary interface.
IRIX--cpeople (User Accounts Manager) has no ASCII interface and runs from a GUI. It also is wrapped around a Web-style interface that should be familiar to operators.
Users sometimes find out about these interfaces from books such as this, manuals, Web sites, or the vendor. If they have root accounts on the systems that they work on, the potential for creating an account that causes problems in your environment is dramatically increased. If users don't understand the environment, they can add conflicting account names, UIDs, or GIDs. You might remember that I said that these tools check for duplicate UIDs and account names, so how can this happen?
It is a very simple process. A user might create an account on his local workstation and pick a random UID or even one the system assigns. If you have a UID and GID table already established for all the users in your community, this user can still create the account on the local workstation. If a copy of the password file that lists every account is not on his workstation, the GUI interface is unaware that the UID is in use. Even if NIS/YP is implemented in the environment, not all account management tools check whether the local workstation is a slave or client to a NIS/YP server. If that local workstation has a duplicate UID with someone on a another remote workstation and the remote filesystem gets mounted, all files with the duplicate user UID are vulnerable and at risk to both users.
If you are unfamiliar with the particular flavor of UNIX, or you need to walk someone through the process of creating a user, one of these tools might provide the easiest and quickest solution.
|
Note - Not all flavors support the creation of home directories across NFS-mounted filesystems when an account is created. You need to check whether it supports this feature. |
Platform: AT&T, BSD
Public domain shell scripts and vendor-supplied or third-party programs are available with features you can configure to work in your specific environment. Some third-party administrative tools are able to support a cross-platform UNIX account management solution. This is both good and bad, because it can make it easier to set up the account, but it can also introduce the potential for damage to your system or environment.
Special features handle password aging, account utilization information, quotas, and UID and GID management. These programs enable you to have more control over home directories, startup files, and other configurable parameters.
If you decide to use one of these packages, do extensive testing of the program before you use it. Any program or application that manipulates the password file on your system should be thoroughly tested. If you are able to obtain the source code for a program, scan the code if you have the experience to verify that the source doesn't damage your system or environment on a local or wide scale.
Platform: AT&T, BSD
The process of adding user accounts has never changed over the years, right down to the format of the password file. The concept on almost all flavors of UNIX remains the same. A user can be added by following these seven steps:
1.Edit the password file and create the required seven fields.
2.Set the password!
3.Add a new GID to the group file if a new number is defined.
4.Create a home directory for the user.
5.Change the permissions and the ownership to the user ID on the home directory.
6.Create or copy any necessary startup files that might be needed or required for the user
7.Test the account!
You have greater flexibility by creating an account manually than you have by using a program or a GUI. By doing it manually, you have the ability to manipulate the password file, home directories, and startup files to a greater extent than you would otherwise. Although GUI vendors try to evaluate many environments and attempt to provide you with the tools to satisfy their needs, your environment might not fall into these categories.
You might have power users such as engineers and programmers who often prefer public domain shells such as bash and tcsh, among others, to work in. In many cases, the GUIs for those shells force you to use a predetermined list to select from and you must go into the password file after the account is created and redefine the shell or use the chsh command. When these predetermined shells are selected in the GUI or from within a program, they often copy a set of startup files that are executed when the user logs in. Creating the account manually gives you greater control over what startup files the user has. You can select those that work best in your environment and can copy them into their home directories.
In addition, you are not limited in the placement of the home directory on the system when you build the account manually. If you want the home directory to reside over an NFS mount point, through a softlink to another filesystem, or to another nonstandard area, you have the ability to place it there without being hit with Invalid Entry error messages. After the home directory is created you can set it with the permissions that meet your standards.
The level of security you want, your environment, and your users all dictate what level of permissions need to be set up.
You can manually go into the password file and create or modify accounts to have the same UIDs (see the section "Delegating root to Multiple Admins" in Chapter 3, "Security," for more information). However, this can have serious repercussions for both root and user accounts. Think first how your environment will be affected and if it is the proper solution to satisfy your needs. The potential for problems is the reason that GUIs and other programs do not allow this.
There are several ways an account can be created. Some are more flexible then others, but all offer the same result in the end: to provide a user with a means to log in to the system.
When setting up accounts for users, keep in mind that users don't change, modify, or add anything in their accounts until they get comfortable with their settings and environment. For this reason, assign users a good temporary password that they can change. Most support people provide users with easy-to-remember and easy-to-crack temporary passwords such as 12345, mike1, and ekim. Give them real passwords. If you give them a good, tough-to-crack passwords and they don't like them, the users are more likely to change them quickly to passwords of their own. If you do decide on a hard-to-crack, fixed, temporary password such as 1x7fee5, make sure you add it to the dictionary file that is part of the cracking program. That way you know who still needs to change their existing passwords.
Man pages:
admintool, chsh, cpeople, passwd, sam, smit
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 5: Account Management |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.
