Certification Objectives 6.02Managing User Accounts

Certification Objectives 6.02—Managing User Accounts

Exam Objective 4.1: Explain and perform Solaris 10 OS user administration, and manage user accounts and initialization files.

Managing user accounts includes creating, modifying, and deleting user accounts. In Solaris 10, you can use the command line and the Solaris Management Console (SMC) GUI for managing user and group accounts. The command line as usual provides more options and hence more flexibility, but it can be complex for a beginner. The SMC GUI on the other hand may be easier to use for a beginner but offers fewer options and less flexibility. However, people with Windows backgrounds may appreciate it.

Exam Watch

The Admintool software from the previous versions is not available in Solaris 10.

Let's begin with exploring how to manage user accounts by using the command line.

Managing User and Group Accounts with the Shell Command Line

Solaris offers several shell commands to manage user and group accounts. In this section we explore these commands to create, modify, and delete user and group accounts.

The useradd Command

You use the useradd command to create a new user account—that is, to add a new user to the system. The account information will automatically go to the passwd, shadow, and group files as you create the account. The syntax for the useradd command is shown here:

 useradd [-c <comment>] [-b <base_dir>] [-d <dir>] [-e <expire>] [-f <inactive>] [-g <group>][ -G <group, group...>] [ -m [-k <skel_dir>]] [-p <profile>] [-A <authorization, authorization,...> [-R <role> ] [-s <shell>] [ -u <uid>] <login-name> 

The options for this command are explained in the following list:

• -c <comment>. It will take any text string, generally a short description of the user (e.g., full name of the user). The information entered here goes into the comment field of the corresponding entry in the /etc/passwd file.

• -b <base_dir>. Specifies the default home directory for the system which will contain the home directories of all the users on the system; for example, if the option -d <dir> is not used for a user with username jkerry, the home directory for jkerry will default to <base_dir>/jkerry.

• -d <dir>. Specifies the home directory of the user for whom the account is being created. If this option is not used, the home directory defaults to <base_dir>/<user_name>. This information goes to the passwd file.

• -e <expire>. Specifies the expiration date for the user account, after which the user will not be able to log on. The date can be entered using any of the formats specified in the template file /etc/datemsk, e.g., 5/9/2007 (the standard American way of referring to dates: month/day/year), or "May 9, 2007." Note that the date that includes spaces must be quoted. The default value for the expiration date on an account is null—that is, no expiration date. This information goes into the shadow file.

• -f <inactive>. Specifics the maximum number of days, expressed in integers, allowed between two consecutive logins; if the user does not log into the account for days more than the value of <inactive>, the account will be locked. The default for this option is 0. This information goes into the shadow file.

• -g <group>. Specifies the primary group for the user. The group may be identified by using the character string name of the group or by using the group ID. This information goes into the passwd file.

• -G <group>. Specifies a secondary group for the user. Multiple groups can be specified by using either the character string names or the group IDs separated by commas. A user cannot become a member of more than a maximum number of groups defined by the variable NGROUPS_MAX specified in the file /usr/include/limits.h. By default, a user may become a member of 15 secondary groups at maximum.

• -k <skel_dir>. Specifies the directory that contains the skeleton files for initializing the user account. The files are copied from this directory to the user home directory during the creation of the account. If you give the -m option along with the -k option, the home directory will be created if it does not already exist. The default skeleton directory is /etc/skel, and if you do use the -k option to specify a new skeleton directory, it must be created before you use the useradd command.

• -p <profile>. Specifies execution profiles, separated by commas, for the user. You will learn more about profiles further on in this book.

• -A <authorization>. A comma-delimited list of authorizations to be assigned to this account. You will learn more about it in Chapter 14.

• -R <role>. Specifies roles, separated by commas, for the user. You will learn more about roles in Chapter 14.

• -s <shell>. Specifies the user's login shell defined by providing the full path name to a program such as /bin/sh. This information goes into the passwd file.

• -u <uid>. Specifics the user ID for the account being created. The default: is the next available number above the highest number already assigned to a user. This information goes into the passwd and shadow files.

As you have seen, there are quite a few options available for the useradd command. A reasonable question to ask is: what value would an option argument have if you did not specify it in the useradd command? In this case, the system would assign it a value called the default value listed in the /usr/sadm/defadduser file. The default values for various option arguments are shown in Table 6-6. You can see the default values by issuing the following command:

    useradd -D 

Table 6-6: Default values for some options in the useradd command (you can change these default values by using the -D option with the useradd command)

Option	Default Value
-b <base_dir>	/home
-e <expire>	Null
-f <inactive>	0
-k <skel_dir>	/etc/skel
-p <profile>	Null
-R <role>	Null
-s <shell>	/bin/sh

Now if you are picky (a wrong word for demanding), you can ask another question: if I don't like any of the system defaults shown in Table 6-6, can I change it? The answer is yes, you can overwrite the system default with your own default by using the -D option with the useradd command, as shown here:

    useradd -D <option> <new_default> 

For example, if you want to change the default for shell from /bin/sh to /bin/ksh, you would issue the following command:

    useradd -D -s /bin/ksh 

It can happen that after an account has been created, you want to specify an option that you weren't concerned about at the account creation time, or you want to change the value of an option. Solaris allows you to do that by offering the usermod command, which we explore next.

The usermod Command

You can use the usermod command to modify an account—that is, to modify the value for an option that cither was specified by you when, the account was originally created or a default value was assigned to it. Solaris lets you modify most of the options as follows:

 usermod [-c <comment>] [-d <dir> [-m] ] [-e <expire>] [-f <inactive>] [-g <group>][ -G <group, group...>] [-1 <new_login_name>[ -m [-k <skel_dir>]] [-p <profile>] [-A <authorization, authorization...>][-R <role> ] [-s <shell>] [ -u <uid>] <login-name> 

Note that the options used with the usermod command are the same as with the useradd command and they are used the same way except for the following two instances:

• -1 <new_login_name>. Specifies the new login name for the user account.

• -m. Moves the user home directory to a new directory specified with the -d option as shown in the following example:

      usermod -d /export/home/johnk -m jkerry 

This command changes the home directory of the user jkerry to johnk. Two points to note here: if the new directory already exists, the user must have read, write, and execute permissions to it, and the files in the previous directory will not automatically be copied to the new home directory; they must be copied manually.

Now that you know how to add a user account to the system and modify it, see the next page for some practical scenarios and their solutions.

Anything in this universe that was created will eventually be destroyed, and a user account is no exception to this law of nature. Employees join and leave the organization, and when an employee leaves the organization, you must eventually delete the account for security reasons if nothing else. In order to accomplish this, the Solaris system offers the userdel command, which we explore next.

SCENARIO & SOLUTION
Which command would you issue to create a user account for a new employee named Bill Clinton. Use bclinton as user name, /export/home/bclinton as home directory, which already exists, and execs as the primary group.	useradd -g execs -d /export/home/ bclinton -s /bin/bsh bclinton
In the next scenario, you need to add another user named Marion Brando; you want to let the default group become his primary group and you want to make the /export/home/mbrando directory his home directory, which does not exist yet. Which command would you issue?	useradd -d /export/home/mbrando -m mbrando
Make the user Marlon Brando a member of another group named "actors."	usermod -G actors mbrando

The userdel Command

You use the userdel command to delete a user account from the system. The syntax for the userdel command is shown here:

    userdel [-r] <login_name> 

The option -r is used to delete the user home directory along with the account. For example, the following command deletes the account of user jkerry along with the home directory (and all directories underneath it recursively):

    userdel -r jkerry 

There may be important company files in the home directory of the employee who has just left. In that case, you can delete the user account without the -r option, and the user account will be deleted without deleting the home directory.

A user must have a primary group. In addition to this, a user can become a member of up to 15 (the default maximum number) secondary groups. Before a user can become a member of a group, the group account must exist. In the next section, we discuss how to manage group accounts.

Managing Group Accounts

You already know from the previous sections how to add users to a group by issuing the useradd and usermod commands with -g and -G options. Before you can add a user to a group, the group account must exist. In this section, you will explore how to add, modify, and delete group accounts.

Adding a Group A group account is created by using the groupadd command which has the following syntax:

    groupadd [-g <gid> [-o]] <group_name> 

The options supported by the groupadd are described as follows:

• -g <gid>. Specifics the group ID. If not used, the group ID will default to the next available number greater than the one already assigned to a group.

• -o. Specifies that the GID can be duplicated—that is, more than one group can share this GID, which is helpful in modifying the group.

The <group_name> obviously is the name of the group and is a character string that may contain lowercase letters and numerals. You can modify an existing group account, and this is discussed next.

Modifying a Group You modify a group by using the groupmod command, which has the following syntax:

    groupmod [-g <gid> [-o]] [-n <new_name>] <group_name> 

The options supported by the groupadd command are described here:

• -g <gid>. Specifies the new group ID.

• -o. Specifies that the GID can be duplicated—that is, more than one group can share this GID.

• -n <new_name>. Specifies a new name for the group.

The <group_name> is the name of the group for which the command is being issued. A group account is internally managed by its GID. If you just want to change the name of an existing group without changing its GID, you can issue the groupmod command in the following form:

    groupmod -o -n <new_name> <existing_name> 

There will be times when you want to get rid of a group. Next, we discuss the command to do exactly that.

Deleting a Group You can delete an existing group by using the groupdel command, which has the following trivial syntax:

    groupdel <group_name> 

For example, the following command will delete the group named gop:

    groupdel gop 

Note that the groupdel command deletes only the group account and not the users that belong to the group. That means that although the group membership of the users is deleted with the deletion of a group, the user accounts still exist.

Exam Watch

Deleting a group does not delete the accounts of the users who were the members of the deleted group.

As opposed to Windows, in UNIX you always use the command line tools for system administration. Nevertheless, there are some GUI tools available for beginners. For example, on the Solaris 10 system, you can use the Solaris Management Console (SMC) GUI tool for user administration. We explore this tool next.

Managing User and Group Accounts with the SMC GUI

You can use the Solaris Management Console (SMC) to manage user and group accounts. In this section, you will do two hands-on exercises using SMC.

Exercise 6-1: Creating a User Account with the SMC GUI Tool

Perform the following steps to create a user account with the SMC GUI tool:

1. Become the superuser or assume an equivalent role (e.g., log in as root).

2. Start the SMC by issuing the following command:

       /usr/sadm/bin/smc & 

3. Click the This Computer icon under the Management Tools icon in the Navigation panel. A list of categories is displayed.

4. Click the System Configuration icon.

5. Click the User Accounts icon.

6. Type in your password.

7. Click the Users icon.

8. Select the Add User With Wizard from the Action menu. Click Next between each of the steps that follow.

9. Type in the user login name at the User Name prompt (following the rules for specifying the user names that you have learned in this chapter)—for example, agore.

10. Optional step. Type in the user full name at the Full Name prompt—for example, Al Gore.

11. Optional step. Type in a further description of this user at the Description prompt.

12. Specify the user ID at the User ID Number prompt—for example, 420.

13. Select the option: User Must Use This Password at First Login, and type in a password for the user at the password prompt. Confirm the password at the Confirm Password prompt.

14. Select the primary group for the user.

15. Create the home directory for the user by accepting the defaults at the Server and Path prompts.

16. Specify the mail server.

17. Review the information you provided and go back to correct the information, if necessary. Otherwise, click Finish.

Congratulations! You have a added a user to the system by using the SMC GUI tool. But before opening the champagne, attempt to log in as the user that you created to be sure that it works.

Groups contain users. You have two choices regarding adding users to a group: you can add the existing users to the group during the group creation, or you could add a user to the group when you create the user account.

Once a user has been created on the system, the user can log into the system and work. Each user works in a certain work environment on the system, which is set up when the user logs in. We explore this topic next.

Shell Initialization Files

As a part of setting up a user account, you need to set up some initialization files that will set up the work environment when the user logs in. These initialization files, also called the shell initialization files, are essentially the shell scripts that set up the characteristics of the user's work environment, such as search path, windowing environment, and environment variables. There are two kinds of initialization files: user initialization files, whose scope is a specific user; and site initialization files, whose scope is the system.

User Initialization Files

The user initialization files live in the home directory of a user. A user works in a specific shell. As shown in Table 6-7, each shell has its own set of initialization files, which exist in the home directory of the user.

Table 6-7: User initialization files for the Bourne, C, and Korn shells (the files are copied into the user's home directory at the time the account is created)

Login shell	User lnitialization Files
Bourne	.profile
C	.login .cshrc
Korn	.profile $ENV It is the environment variable that specifics the file (usually .kshrc) that will define the user's environment

A question arises: where do these files come from, and how do they end up in the user's home directory? Solaris 10 offers the skeletons for the user initialization files in the /etc/skel directory, as shown in Table 6-8.

Table 6-8: Default user initialization files for the Bourne, C, and Korn shells (copied to the user's home directory when you create a user account)

Login Shell	Default Initialization Files
Bourne	/etc/skel/local.profile
C	/etc/skel/local.login /etc/local.cshrc
Korn	/etc/skel/local.profile

When you create a user with the useradd command by using the -k and -m options, this set of skeleton files, depending upon the user's login shell, is copied into the user's home directory and renamed to the names shown in Table 6-7.

On the Job 

Including $path (C shell) and $PATH (Bourne and Korn shell) in the command that sets the path includes the existing path value before the command is issued. This is used to append the user's path settings to the ones that are already set in the site initialization file. If you do not use $PATH or $path, the existing path settings will be replaced with the new ones.

Of course, you can edit the initialization files in the /etc/skel directory and edit the initialization files in the home directory to customize them. Typically, the user will customize the local work environment by editing the user initialization files, whereas you will customize the user's work environment by providing the systemwide site initialization files, which we discuss next.

Site Initialization Files

Site initialization files allow you to add new functionalities to the work environments of all the existing users on the system. You would typically put these files on a server to make them accessible to all the users on the site. A user initialization file will access a site initialization file with a statement in the beginning of the file—that is, the site initialization file will be executed before the user initialization file. In case of a conflict, the value of a variable set in the user initialization file will override the one set in the site initialization file. Note that a user initialization file and the site initialization file that it refers to must use the same shell script.

The site initialization files on a system usually exist in the /etc directory. The standard site initialization files are /etc/profile for the Korn and Bourne shells and /etc/.login for the C shell. You can create any other site initialization file with any name on a server and then place its entry at the beginning of a user initialization file.

Order of Execution for the Initialization Files

When a user logs in, the work environment for the user is set up by automatically executing the initialization files in the order shown in Table 6-9.

Table 6-9: Order in which the initialization files are executed for C shell, Bourne shell, and Korn shell when a user logs in

Step	C Shell	Bourne Shell	Korn Shell
1	/etc/.login	/etc/profile	/etc/profile
2	$HOME/.cshrc	$HOME/.profile	$HOME/.profile
3	$HOME/.login	—	$HOME/$ENV It's usually the .kshrc file.

Note that the C shell has two .login files, one in the /etc/ directory that the system administrator—that is you—would manage, and the other one for individual users in their home directories. This way the users can customize their individual login environments. The same thing is true for Bourne shell and Korn shell; the file name in those shells is profile instead of login.

Now that you theoretically know how the initialization files work, here are some practical scenarios and solutions to consider.

SCENARIO & SOLUTION
You want the PATH variable of each user to include the paths /usr/bin and /usr/sbin. How will you do this?	Set this path in a site initialization file; for example, for the C shell enter the following line in the /etc/.login file: set path=( /usr/bin /usr/sbin) For the Bourne or Korn shell, enter the following line in the /etc/profile file: PATH=/user/bin:/usr/sbin; export PATH
The user Marlon Brando informs you that he wants to include his current directory and the /usr/local/bin directory into his path variable. What would you advise him to do?	If the user uses C shell, edit the $HOME/.cshrc file and enter the following line into it: set path=($path /usr/local/bin .) If the user uses the Bourne or Korn shell, enter the following line into the $HOME/.profile directory: PATH=$PATH:/usr/local/bin:.; export PATH

The three most important takeaways from this chapter are listed here:

• A user account can be created by using the useradd command, and it is composed of several components such as login name, UID, password, and home directory.

• Once a user account has been created, the information about the user account lives in the /etc/passwd and /etc/shadow files.

• When a user logs into the system by using the corresponding account, the work environment is created by automatically executing the site initialization files, followed by the execution of user initialization files.

Why would a user have an account on a system? The answer is obvious: to access and use system resources. Not every user needs to access everything on the system. So, once you have set up the user accounts on a system, the next obvious question would be: what can and cannot a specific user access on the system? This is a security issue whose importance cannot possibly be overstated This is true especially in the brave new world of the Internet whereby your system may be connected to the outside world, and it's a wild world out there. Yes, you can say "it's the security, stupid." The system's security is an integral part of user management. We explore the system security aspect of the user administration in the next chapter.