| Now we're ready to move on and add some users to our system. We've chosen to add the four listed in Table 3.2. Table 3.2. User DetailsReal Name | Login Name | UID | Group | GID |
|---|
Test User | testuser | 500 | test | 100 | System Administrator | sysadmin | 1000 | sysadmin | 14 | Mike Smith | msmith | 1001 | staff | 10 | John Green | jgreen | 1002 | staff | 10 |
The reasons for selecting these users are as follows: Test User: Creating this user allows us to test a variety of things, such as login scripts and checking initialization files, safe in the knowledge that we won't damage the running system. For this reason, test users will also be maintained along with all the standard users, although they will be placed in their own group. System Administrator: One of our important users. These users will be allowed to carry out some system administration tasks. We'll use RBAC later in the chapter to create and control them. This means that instead of logging in as root and having access to any command, we'll just let them have access to the commands we want them to run. This will (hopefully!) ensure that users are less likely to accidentally run some command with disastrous affects. Mike Smith/John Green: Two of our genuine userswe'll use these to show examples of useradd and our custom script later.
Our "Company Standards" One of the first steps we need to take is to produce a set of standards that will be used throughout the company/department whenever we wish to add users. For example, should the login names be their first names only (not a good idea as we would soon run out of logins), or should we have the first initial followed by the next three characters of the surname? In a similar way, every other parameter is best decided upon before any users are added; otherwise, the system can become awkward to administer very quickly. The following is a list of standards that we have decided to use for all the users we add: The login names will be based on a combination of the user's surname and first initial. We will limit them to eight characters, leaving up to seven characters for the surname. UIDs will be allocated sequentially. Having a certain number of UIDs available for each department, say 1,000 for sales, 2,000 for engineering, and so on, could be used to allocate UIDs, but this is really why the group file is there. Using that mechanism can also make it awkward to administer the UIDs as users are added and deleted later. We will split users into groups by department or function; for example, some groups we will implement are sales, software, and marketing. Doing this will allow us to restrict access to documents within each specific batch of users as required. All users will use the Korn Shell (see Chapter 5, "Shells"). We will set up some global start-up files to easily maintain them by linking users to this global file where possible. All users' home directories will be located in /export/home. All users will be created with a default password of "changeme" and will be forced to change it at first login. Password aging will be used to force users to change their password at predefined intervals, this being 60 days. The system will warn users five days before the password expires that it requires changing.
Now let's start to create the users. There are various ways that this can be donesome easier than others. The first, and recommended way is by using a command named useradd or one of its variants (groupadd, roleadd, and so forth). These are the command line equivalents of the GUI admintool and are the methods we'll look at for the majority of users. They will perform all the tasks necessary to create the user, including things like making sure that duplicate UIDs aren't used. A second method is to update all the relevant system files manually. This is a common task carried out by many system administrators, but the responsibility of getting things correct also rests with themthe system cannot check that everything has been carried out correctly. A third method is to create a custom script that will enable us to "automate" the tasks that we need to perform to add the users and apply company-specific settings at the same time. Again, this is a common way to add users, often written as shell scripts, Perl scripts, or C programs. We'll actually create a simple example, based on useradd, at the end of this chapter. Adding a Test User with Groupadd and Useradd To demonstrate the use of useradd, we'll create the test user and associated group first. First let's create the group as follows: hydrogen# groupadd -g 100 test hydrogen# Now check that the group has been successfully added to the /etc/group file: hydrogen# grep test /etc/group test::100: hydrogen# Good. We've defined the new group, so we can go ahead and create the test user: hydrogen# useradd -c "Test User" -d /export/home/testuser -g test -m -k /etc/skel -u 500 -s /bin/ksh testuser 6 blocks hydrogen# If we look at the entry that has been created in /etc/passwd, we can see there is an "x" in the password field. This indicates there is a corresponding shadow entry, as we mentioned earlier: hydrogen# grep testuser /etc/passwd testuser:x:500:100:Test User:/export/home/testuser:/bin/ksh hydrogen# Looking at the /etc/shadow entry, we can see the password is set to the locked string "*LK*" to show the account is locked. The account is automatically locked after it has been created with useradd: hydrogen# grep testuser /etc/shadow testuser:*LK*::::::: hydrogen# We could also have checked the password state by running the passwd command. This will display the status of the account and any aging details if they've been set. In this case it again confirms the password is locked: hydrogen# passwd -s testuser testuser LK hydrogen# Setting the Password We need to unlock the account before the user can login, so we will do that by allocating a password to the user using the passwd command. hydrogen# passwd testuser New password: <enter user's password> Re-enter new password: <enter user's password> passwd (SYSTEM): passwd successfully changed for testuser hydrogen# If we again check the shadow file, we can see that the user now has a valid password entry and can log in to the account correctly. Notice the password is encrypted and field 3 displays when this was altered. This is shown as the number of days since January 1, 1970. hydrogen# grep testuser /etc/shadow testuser:ba7btwLghQU86:10912:::::: hydrogen# As seen here, passwd will show us that the account has a valid password assigned: hydrogen# passwd -s testuser testuser PS hydrogen# Now, let's reset it to our standards for the company, which are five days warning and 60 days valid: hydrogen# passwd -f -w 5 -x 60 testuser hydrogen# Looking at the shadow file, we can see the settings have been applied. Fields 3 and 4 are both set to "0" to force users to change their passwords at the next login. hydrogen# grep testuser /etc/shadow testuser:ba7btwLghQU86:0:0:60:5::: hydrogen# Once more, if we check this via passwd, it will also show the following aging details: hydrogen# passwd -s testuser testuser PS 00/00/00 0 60 5 hydrogen# Testing the Account At this point, we can confirm that the user has been set up correctly by switching to that person's account. To do this, we'll run the following command and should see that the system offer us the user's default prompt: hydrogen# su - testuser hydrogen$ The "-" option will force su to reset the new environment to that of testuser. Once we have logged in and proven the account is OK, we can exit back to the root shell: hydrogen$ exit hydrogen# Modifying with Usermod Usermod allows us to modify the user's definition. As an example, we'll modify testuser so that it is included in additional groups such as sys and adm. First, let's confirm that testuser is only in the one group at present. We can do this by using grep to search the /etc/group file as we have shown previously, or by running a command named groups, as shown below: hydrogen# groups testuser test hydrogen# Now that we know that testuser is only in the test group, let's modify its settings: hydrogen# usermod -G sys,adm testuser 6 blocks hydrogen# Checking the group file shows the details have been added correctly: hydrogen# grep testuser /etc/group sys::3:root,bin,sys,adm,testuser adm::4:root,bin,sys,adm,testuser hydrogen# Similarly, if we run groups, it provides us with a similar confirmation: hydrogen# groups testuser test adm sys hydrogen# Removing the User The account has now been created and we have finished with it for the moment, so we want to ensure the system is secure by making sure no one is allowed access to it. We could achieve this by either deleting or locking the account. Deleting it would remove it from the system and mean that we cannot use it again for testing and so forth, while locking the account allows us to simply lock or unlock it at will. If we wished to delete it, we could run the userdel command as shown below: hydrogen# userdel -r testuser hydrogen# Rather than remove the account, let's retain it for the moment, as this will allow us to use it to test similar user tasks. Therefore, we'll lock the account to ensure that it is secure: hydrogen# passwd -l testuser hydrogen# Now we can check that the account has been locked; passwd will provide this information for us and also show the date the password was altered: hydrogen# passwd -s testuser testuser LK 12/25/99 0 60 5 hydrogen# Useradd Defaults When adding users with useradd, it's possible to configure some settings that can be used as defaults. Let's take a look at these to see what they are currently set to: hydrogen# useradd -D group=other,1 basedir=/home skel=/etc/skel shell=/bin/sh inactive=0 expire= hydrogen# This shows that we need to alter a couple of the values to fall in line with our standardsthese being the basedir, group, and shell values. The first problem we can see is that useradd will not allow us to change the default shell. We'll look at this problem in a minute. First, let's set the default group to be staff, and the basedir directory to be /export/home: hydrogen# useradd -D -g 10 -b /export/home group=staff,10 basedir=/export/home skel=/etc/skel shell=/bin/sh inactive=0 expire= hydrogen# Good. The details have been altered correctly. Once the default values are changed, they are written away to a file named /usr/sadm/defadduser. This doesn't exist by default; it's created the first time this command is run. If we look at the file we'll find it now contains the following details: hydrogen# cat /usr/sadm/defadduser # Default values for useradd. Changed Wed Nov 17 12:13:00 1999 defgroup=10 defgname=staff defparent=/export/home defskel=/etc/skel defshell=/bin/sh definact=0 defexpire= hydrogen# This shows the new settings, along with the current default shell value. Defadduser is simply a text file, read by useradd, so let's manually alter the defshell variable and set it's value to /bin/ksh: hydrogen# <edit /usr/sadm/defadduser and alter defshell=/bin/sh to defshell=/bin/ksh> hydrogen# grep defshell /usr/sadm/defadduser defshell=/bin/sh hydrogen# If we again run useradd to display the current default settings, we can see that the shell has been altered correctly: hydrogen# useradd -D group=staff,10 basedir=/export/home skel=/etc/skel shell=/bin/ksh inactive=0 expire= hydrogen# Now that we've got the correct default values set, we can easily create users by specifying the minimum amount of information, such as that shown below: hydrogen# useradd -c "Test User" -m -u 500 testuser 6 blocks hydrogen# Manually Updating the System Files We mentioned at the beginning of this chapter that we would also show some shortcuts for adding users. We'll do that here, but before we do, we need to be aware that using these methods can be unsafe. The reason for this is that using them removes the safety checks built into programs such as useradd. For example, these programs maintain a backup copy of the major files and also perform some error checking, such as making sure the user doesn't already exist and that a unique UID is used. However, for performing quick changes and things such as root password recovery, the manual method is ideal, and sometimes a necessity. Let's run through the steps here by creating one of our "standard" users, msmith, a member of the staff group. We'll begin by checking the group file to ensure the staff group is there (it should be as it's a default group): hydrogen# grep staff /etc/group staff::10: hydrogen# Next, we'll create an entry for the user in /etc/passwd by editing it with our favorite editor. After the changes have been made it will look like the following: hydrogen# grep msmith /etc/passwd msmith:x:1001:10:Mike Smith:/export/home/msmith:/bin/ksh hydrogen# Now, we'll create the corresponding entry in /etc/shadow. This should contain the entry shown below after it has been altered: hydrogen# grep msmith /etc/shadow msmith:*LK*:0:0:60:5::: hydrogen# Here we have added the correct line, locked the account, and set the values for the expiration and warning days. Now let's create the user's home directory: hydrogen# mkdir p /export/home/msmith hydrogen# Solaris supplies a series of set-up files that are available for users. These are located in /etc/skel and named local.profile, local.cshrc, and local.loginthese being for the Korn, Bourne, and C Shells. Useradd will copy the correct file into the user's home directory when it is created (renaming it in the process), but we need to do that manually here. We'll do that now for the particular shell that is being used, which in this case is the local.profile for the Korn Shell (see Chapter 5, "Shells"): hydrogen# cp /etc/skel/local.profile /export/home/msmith/.profile hydrogen# Now that we have all the basic files in place, we need to ensure that msmith can work with them and that he has permission to create files within his home directory. Let's change the ownership of it now, along with any files beneath it: hydrogen# chown -R msmith:staff /export/home/msmith hydrogen# If we now list the newly created directory, we should see something similar to that shown below: hydrogen# ls -ld /export/home/msmith drwxr-xr-x 2 msmith staff 512 Oct 22 1999 /export/home/msmith hydrogen# Now that the user has a valid home directory, we can set the password, which we'll do as follows. This will allow him to log in, but because we've also forced him to change his password at login time (fields 3 and 4 are set to "0"), he will be prompted to enter a new one: hydrogen# passwd msmith New password: <enter user's password> Re-enter new password: <enter user's password> passwd (SYSTEM): passwd successfully changed for msmith hydrogen# Good. Everything is in place; so let's test the account by trying to login as the user: hydrogen# su - msmith hydrogen$ pwd hydrogen$ /export/home/msmith hydrogen$ exit hydrogen# Good. Msmith has now been added to the system. This example shows that manually adding users is not a difficult task to performwe just need to be careful and apply a few checks along the way. Real and Effective IDs We've come across the su command in a number of places now. In Chapter 1, it was to switch from a "normal" user to root, and in this chapter to switch from root to a "normal" user. Before we move on, let's take a brief look at some of the changes that occur when we run this command. We already know that all users have a UID and GID associated with themwe've set these in the password file and can confirm what these are by running the id command, as shown below: hydrogen# id uid=0(root) gid=1(other) hydrogen# When you switch to another user, you need to inherit the UID and GID of the new user; otherwise, you won't be able to access the same files as that user. However, the system still needs to retain your original UID and GID so that it can reset correctly when you exit back to yourself. It accomplishes this by assigning you an "effective" UID and GID, known as your EUID and EGID, respectively. To show this, let's run the id command again, but this time we'll switch to testuser first: hydrogen# su testuser hydrogen$ id uid=500(testuser) gid=100(test) hydrogen$ Just as we expectedthe system now believes that we are testuser. However, we can still determine our original values using a number of commands, including who, as shown below: hydrogen$ id uid=500(testuser) gid=100(test) hydrogen$ who am i root console Feb 16 13:34 hydrogen$ | 
