Usernames and User IDs

For every account you create, you must create a username. Usernames must be unique within an organization. In fact, if you try to create a duplicate username, you will get this error message:

Warning! This user name is already being used in the name service user map.

To help alleviate potential naming issues, it's a good idea to use or create a company-wide usernaming standard. Some common ones are to use the user's first initial and last name, or the first five characters of the user's last name and first initial. Using the two options, the user Joe Smith would have a login of jsmith or smithj. Usernames in Solaris must be between two and eight characters, and can contain uppercase and lowercase letters, numbers, periods, hyphens, and underscores.

Also be sure that usernames are distinct from any mail aliases known to the system. Problems can occur when a username duplicates a mail alias.

Each user account is associated with a User ID (UID). UIDs can be any integer between 0 and 2147483647, the maximum value of a signed integer. UIDs in the 0-99 range are reserved for system accounts and should not be used for regular user accounts. Although a UID can be as large as 2147483647, it is not recommended that you create users with a UID greater than 60000. UIDs 60001 and 60002 are the default users nobody and noaccess.

Users with a UID greater than 60003 might experience difficulties, including NFS and NIS usage issues, problems using the ps -l, cpio, ar, and tar commands, and compatibility problems with older Solaris versions that did not recognize UIDs of greater than 65534.

Not only does the UID identify users, but it is also used by systems to identify the owners of files and directories. In the example we used earlier with 10 users and 10 workstations, the best way to approach creating users on all machines would be to make certain that the users had the same username on each machine and the same UID. This would ensure that users wouldn't have ownership problems when transferring files between computers.

Users cannot be created with an existing UID but can be later modified to share an existing UID with another user. Although this is possible, creating duplicate UIDs can cause serious security problems, and is not recommended.

Graphical Administration Tools

Solaris 9 has two bundled graphical utilities that can be used to manage users: Admintool and the Solaris Management Console (SMC).

Admintool is the interface that many Solaris administrators are used to. However, when you open Admintool in Solaris 9, you receive a warning: Admintool will be phased out, so you had better find another tool you like. To view users in Admintool, open the utility and choose Browse ➣ Users. Adding, modifying, and deleting users is done from the Edit menu. The Admintool: Add User window is shown in Figure 4.2.

Figure 4.2: Adding a user with Admintool

As you can see in Figure 4.2, there are three major sections to the Add User window: User Identity, Account Security, and Home Directory. Each of the fields represented in Figure 4.2 is explained in Table 4.2.

The new graphical user management tool of choice is the Solaris Management Console (SMC). The graphics in the SMC are much better than the ones in Admintool, and SMC gives you more options for managing users. For example, you can add multiple users with a wizard, assign rights to users, create user account templates, and set user policies.

SMC enables you to view users in various ways: large or small icons, List view, Details view, and even Web Style. Figure 4.3 displays users in Details view in SMC.

Figure 4.3: Solaris Management Console- User Accounts

To modify a user account, highlight the user and choose Action ➣ Properties, or double-click the user. Figure 4.4 displays the User Properties window.

Figure 4.4: User Properties

User Properties in SMC has nine tabs that enable you to configure various aspects of a user's account. The tabs are explained in Table 4.3.

To delete a user from SMC, highlight the user and choose Edit ➣ Delete, or right-click the user and choose Delete.

If you are going to use a graphical tool to manage your users, the SMC is more convenient and provides more flexibility than Admintool. For the certification exam, though, you will be expected to know how to add, manage, and delete users from a command prompt.

Adding Users From a Command-Line Interface

The useradd command is for adding users from a command prompt. The syntax for useradd is as follows:

# useradd arguments login

No arguments for the useradd command are required. Therefore, if you wanted to add a user named sjohnson, all you need to type is this:

# useradd sjohnson

But what fun is that? You added a user with all default settings and didn't use any switches. It might have been easy to type, but it positively lacked any sort of customization or creativity. And it certainly wouldn't be any fun to write test questions about a boring command, would it?

While programming arguments for useradd, the developers at Sun nearly exhausted the alphabet. It's a good thing that Solaris is case-sensitive because that gave the developers twice as many possibilities to use. The useradd options are listed in Table 4.4.

Table 4.4 might seem to contain a lot of options, but considering the flexibility required to create new user accounts, the arguments are necessary. Perhaps the most interesting switch is -D. It enables the administrator to set a default value for one of the supported options (-A, -b, -e, -f, -g, -P, -p, or -R). Any users subsequently added to the system will be assigned the new default value.

As an example, the default for the primary group (-g) is other (GID 1). However, consider the following command:

# useradd -D -g trainers
# useradd thudson

The new user, thudson, will have a primary group of trainers (this group must already exist, or you will receive an error message). All subsequently added users will also be assigned to this primary group, unless specified otherwise with the -g switch.

There is one potentially negative aspect to adding users through useradd. Users created with useradd have no password, and their accounts are disabled by default. To enable the user account, you must use the passwd command to set a password. If you have just created the thudson account with useradd, you would need to enable the account by using the following command:

# passwd thudson

Supply a password (even if it is blank), and the account will be enabled.

Modifying and Deleting Users From a Command-Line Interface

The usermod and userdel commands are used to modify and delete users. In most cases, it's easier to use the graphical tools for user management. However, there are some tasks that you cannot complete unless you use the command-line tools. For example, changing a user's UID is done through the usermod command, and cannot be done through a graphical interface.

The usermod command supports most of the same arguments that useradd does. The exceptions are -b, -D, -k, and -p, which do not exist. The -l switch is unique to usermod and enables you to create a new login name for the user. The -m option (when used in conjunction with -d) will move the existing user's home directory to the new directory location, instead of creating a new empty home directory.

Sun recommends not changing the user's login name or UID for any reason. However, some reasons for changing the user's login name, such as marriage or a legal name change, make sense. It's still not recommended to change the user's UID for any reason.

Let's say you want to modify the user jgebelt. She has recently been promoted (necessitating a primary group change) and has long wanted to use the C shell instead of the Bourne shell. You would execute the following command to modify her account:

# usermod -g cpuguru -s /bin/csh jgebelt

She will now have the cpuguru group as her primary group and the C shell as her default shell.

Deleting users is accomplished with the userdel command. There is only one switch for userdel: -r. The -r option deletes the user's home directory and any files and subdirectories. The syntax for userdel is the same as the other user* commands:

userdel -r username

Home Directories

A home directory can be provided to users as a place to store their personal files. As an administrator, you can place home directories on local machines or on a centralized server. If you have a large number of users, placing home directories on a server facilitates backups. Sun recommends that user home directories be created as /export/home/username, whether they are located on a server or local machine.

Regardless of where the user's home directory is located, users should access the directory through a mount point called /home/username. When using AutoFS to mount file systems, the /home mount point will be reserved specifically for home directories.

Home directories can be created when the user's account is created. If the user already has an account but no home directory, create the directory manually. Then modify the user's properties to specify the location of the home directory.

Password Management

To log in to Solaris, users must provide a valid username and password. Usernames are often public knowledge or at least company-wide knowledge. In most companies, if you know a person's first and last name, you can figure out their username quite easily. Passwords should be a different story because the password is the only obstacle between the potential hacker and critical network resources.

Passwords can contain any keyboard character and should contain a combination of uppercase and lowercase letters, numbers, and special characters, such as $, %, @, or whatever the user prefers. Passwords must be at least six characters, and the first six characters must contain at least two alphabetic characters and at least one numeric or special character. Although passwords in Solaris can be more than eight characters long, only the first eight are processed during user authentication.

To increase network security, force users to change their passwords periodically. How often depends on how strict of a security environment you have. Once every six weeks is appropriate for many networks, although users in less-secure installations can possibly afford to change their passwords every three months.

Information that can be easily guessed should not be used for any password. Any part of the user's name, the user's significant other, children, or pets' names, and important numbers (Social Security number, driver's license number, telephone number) should be avoided at all costs. Nonsense words make the best passwords, and users should avoid any words listed in common dictionaries.

All of this might sound a bit paranoid, but when it comes to security, it's better to err on the side of safety. If a user uses his first name as his password, it's incredibly easy to figure out. More complex password-cracking programs will run a "dictionary test." If the user's password appears in a dictionary, the program will eventually find it.

Solaris 9 has a feature called password aging, which enables an administrator to force users to change their passwords periodically or to prevent users from changing their passwords too frequently. (When users change their passwords too frequently, they are apt to forget their password.)

The best way to secure your network and protect passwords is to educate your users. Many users don't understand the severity of security risks and they don't understand what they can do to help protect the network, their data, and the company. When educated as to proper password use, users can be security allies instead of unwitting security risks.

Graphical Administration Tools

The Admintool and Solaris Management Console are available for managing groups as well as users. In Admintool, click Browse ➣ Groups to see a group listing. Groups can be added, modified, and deleted from the Edit menu. Even though Admintool is older and has fewer features than SMC, it does have one very useful element: it shows the members of the groups. Figure 4.5 shows the Groups node of Admintool.

Figure 4.5: Admintool- Groups

Adding a group in Admintool is easy. Choose Edit ➣ Add to access the window shown in Figure 4.6. Supply a group name, GID, and group members.

Figure 4.6: Adding a group in Admintool

To modify or delete a group, highlight the group and choose either Edit ➣ Modify or Edit ➣ Delete.

It's true that the SMC often outperforms Admintool. However, group management in SMC has some minor inconveniences. When viewing groups in the SMC main window, you can see the group name and GID, but you can't see the group members. To view group members, you must double-click the group to view its properties. The Groups node of SMC is shown in Figure 4.7.

Figure 4.7: Solaris Management Console Groups

Adding groups in SMC is easier than it is in Admintool, because you can see the list of users on your system. There is one minor annoyance with adding groups in SMC though. The Group ID Number box is far too small to see the whole number (the GID in Figure 4.8 is 5150, not 50) unless you leave the help portion of the screen up when you open the Add Group box. Perhaps this and the viewing group membership issue will be fixed in a later release. Figure 4.8 shows the Add Group dialog box in SMC. To get there, click Action ➣ Add Group.

Figure 4.8: Adding a group in Solaris Management Console

You can add users to a group or modify group properties by double-clicking the group, or by highlighting the group and choosing Action ➣ Properties. Groups are deleted by right-clicking the group and choosing Delete, or by choosing Edit ➣ Delete.

Command-Line Interface

From the command line, groups can be added, modified, and deleted with the groupadd, groupmod, and groupdel commands.

The syntax for the groupadd command is as follows:

# groupadd -g gid -o groupname

The groupadd command has only two possible switches: -g to specify a certain GID, and -o to enable duplicate GIDs to be created. As with duplicate UIDs, it's not a good idea to create duplicate GIDs.

To modify a group, use the groupmod command:

# groupmod -g gid -o -n name groupname

For example, if you wanted to rename the techs group to support, and change the GID to 1814, you would issue the following command:

# groupmod -g 1814 -n support techs

To delete a group, use the groupdel command. To delete the group, you must supply the group name as an argument for the groupdel command. You cannot supply the GID. To delete the acctng group, issue this command:

# groupdel acctng

To add users to groups, you must use the usermod command. None of the group management commands support adding users.

/etc/passwd

The /etc/passwd file holds critical user account information, such as usernames and UIDs. There are seven fields in the /etc/passwd file, separated by colons. Here are the seven fields:

username:password:UID:GID:comment:home_directory:login_shell

Most of the fields are self-explanatory if you have already read the section in this chapter on creating users or you are already familiar with user creation. However, the password field in this file needs some explanation. Every user will have an x in their password field, which serves as a placeholder for the user's real password.

Older versions of Solaris (and other UNIX-based operating systems) used to put the password, in encrypted form, right in the /etc/passwd file. The problem is, users need read access to /etc/passwd to log in. Therefore, all users had access to all passwords in the system, including that of the root account. Yes, the passwords were encrypted, but brute force hacking methods could still decode them. After a user had the root password, they could do anything they wanted, benign or otherwise.

To solve this problem, the /etc/passwd file contains a mere placeholder, and the encrypted password is stored in a second file, /etc/shadow. More on /etc/shadow in the next section. Here is a sample /etc/password file:

root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:
qdocter:x:100:10:author:/export/home/qdocter:/bin/sh

Every user created on the system will appear in the /etc/passwd file. As you can see, every user has an x placeholder after their username, followed by the user's UID and the GID of the user's primary group.

Although it's possible to directly edit the /etc/passwd file to add, modify, and delete user accounts, it's not recommended. Instead, use your favorite graphical utility or the useradd, usermod, and userdel commands. Editing the /etc/passwd file directly does not modify the critical /etc/shadow directory, whereas using the user management utilities does.

To verify the integrity of /etc/passwd, you can use the pwck command.

/etc/shadow

The /etc/shadow file holds all usernames and information regarding the user's password. The fields for /etc/shadow are as follows:

username:password:lastchg:min:max:warn:inactive:expire:flag

Table 4.5 explains the fields in /etc/shadow.

Here is a sample /etc/shadow file:

root:AaSfeBzrNVeao:11920::::::
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
lp:NP:6445::::::
uucp:NP:6445::::::
nuucp:NP:6445::::::
smmsp:NP:6445::::::
listen:*LK*:::::::
nobody:NP:6445::::::
noaccess:NP:6445::::::
nobody4:NP:6445::::::
qdocter:DXvo9wTm2tZmQ:11899:5:42:7:21::

You can see that the qdocter user account created on this system has a 5-day minimum and 42-day maximum password life, a 7-day warning window, a 21-day inactive grace period, and no expiration date.

If you have manually created or modified users in the /etc/passwd file, the pwconv command can be used to automatically update the /etc/shadow file. Again, this method is not recommended for creating or modifying users.

/etc/group

The /etc/group file contains-you guessed it-group information. Although users can belong to multiple groups, the user is associated only with their primary group in this file. (This is not true for built-in administrative accounts, which appear multiple times.) Listing all group memberships could quickly become unwieldy, especially on larger networks. The /etc/group file has four fields:

group_name:password:GID:users

The password field is optional. Most groups do not require passwords, but passwords can be used for security purposes. If a group has a password, a user will be required to supply it if they try to use the newgrp command to change their primary group. Here is a sample /etc/group file:

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin::14:
smmsp::25:smmsp
nobody::60001:
noaccess::60002:
nogroup::65534:
kids::100:ldocter,adocter
macaddct::102:mgantz
boss::103:kdocter
author::104:qdocter

None of the preceding groups has a password, but then again, none of them need one. You can verify the consistency of the /etc/group file with the grpck command, which is identical in usage to pwck.

Seeing Who Is Logged In

There might be several reasons why you want to see who is logged in to your system. Perhaps you need to change the run level to S to perform a system backup and want to warn users. Maybe you think someone who shouldn't be logging in is logging in. Or you might be just curious. Any reason is good enough. The basic command to see logged-in users is who. The who command examines the /var/adm/utmpx file to obtain information on current connections.

To see a historical listing of all logins and logouts on your system, use the last command. This command checks the /var/adm/wtmpx file for all logins and logouts. The last command can display quite a bit of information, too much to sift through in a lot of cases. To help squelch output, use the last -n number command, which will display only the number of lines you request.

Switching Users

If you are the administrator of your network, you probably realize that it's not a good idea to log in to your machine as root and leave the superuser account logged in all day. If you were to leave your desk for any reason, another person could use your machine to perform malicious tasks.

A good way to give yourself administrative access while protecting your network is to create a normal user account for yourself and to use the su (switch users) command to assume administrative powers when you need them. After you are done with your administrative duties, you can go back to using your regular user account.

If you use su with no arguments, Solaris assumes that you are trying to switch to the superuser account and will prompt you for the superuser password. You can, however, su to any valid user or role on your system. Instead of just typing su, you can issue the command with a username argument, such as su jdoe. Again, you will be prompted for the user account's password.

All attempts to use the su command are logged in /var/adm/sulog file. The sulog file records where, when, and who attempted to su, and the result of the attempt. Here is an example from a sulog file:

SU 07/26 11:43 + pts/4 qdocter-root
SU 07/29 13:20 + pts/4 qdocter-root
SU 07/29 16:11 - pts/3 jmartin-root
SU 07/29 16:12 - pts/3 jmartin-root
SU 07/29 16:13 - pts/3 jmartin-qdocter
SU 07/30 10:01 + pts/4 qdocter-root

All entries start with SU and the date and time of the su attempt. The plus indicates a successful su, whereas a minus indicates a failure. The first username listed is the account that attempted to su, and the second account name listed is the account that the user attempted to switch to.

In the example, it can be concluded that the jmartin user account does not have administrative access and is trying to hack the root password. For security purposes, it's a good idea to periodically monitor the sulog file.

After you have successfully used su, your command prompt will change from that of a regular user ($, if you use the Bourne or Korn shells) to the superuser, #. Otherwise, your environment will stay the same. To assume the environment (in addition to the identity) of the user you are changing to, you could use su - username. To "un-su" yourself, press Control+D on your keyboard, or type exit and press Enter.

Changing User Passwords

Passwords can be changed in Solaris through either a graphical user interface or the command line. The graphical tools are Admintool and the Solaris Management Console, which are described earlier in this chapter. In Admintool, passwords can be cleared but not changed. From a command line, use the passwd command.

If you are the superuser or have equivalent rights, you can change any user's password by using the passwd command. If you are a regular user, you can change only your own password.

Real World Scenario: Catching Would-Be Hackers

You are the network administrator for a technical consulting firm. One afternoon, you receive a call from one of your users, Steve. He's frantic because he believes that one of his coworkers, Jason, has gone off the deep end. Jason has been making off-handed comments about hacking the network. Apparently this would-be hacker is disgruntled and wants to harm the company by destroying large amounts of sensitive data.

Steve says that he normally wouldn't consider it a big deal, but Jason's rhetoric has become stronger in recent weeks. That, and Jason claims to have the "ultimate hacking program" that would guarantee his success. Steve is worried and wanted to warn you.

You have a potential hacker on your hands and you need to stop him. The question is, how? You need proof that Jason is trying to behave in a malicious manner. So what do you do?

If you suspect that someone is trying to hack the superuser account, one of the first places you should check is the /var/adm/sulog file.

Sure enough, when you check the file, there are literally thousands of lines indicating that Jason has been trying to use the su command to assume administrative control. Fortunately, he hasn't had any success so far. You now have the proof you need to confront Jason's manager with your suspicions.

This time, you were lucky enough to get a tip from a concerned user that someone was trying to hack the superuser account. But is there anything you can do to help yourself, so you don't need to rely on conscientious users? There is. By editing the /etc/default/su file, you can set up your system to pop up a display on the console each time the su command is used in an attempt to gain superuser access. To activate this option, uncomment the CONSOLE=/dev/console line in /etc/default/su.