Users

 

Users

 


 

Managing User Accounts and Resource Access

Managing user accounts and groups is an essential part of system administration within an organization. But to do this effectively, a good system administrator must first understand what user accounts and groups are and how they work.

The primary reason for user accounts is to verify the identity of each individual using a computer system. A secondary (but still important) reason for user accounts is to permit the per-individual tailoring of resources and access privileges.

Resources can include files, directories, and devices. Controlling access to these resources is a large part of a system administrator's daily routine; often the access to a resource is controlled by groups. Groups are logical constructs that can be used to cluster user accounts together for a common purpose. For example, if an organization has multiple system administrators, they can all be placed in one system administrator group. The group can then be given permission to access key system resources. In this way, groups can be a powerful tool for managing resources and access.

The following sections discuss user accounts and groups in more detail.

 

Managing User Accounts

As stated earlier, user accounts are the method by which an individual is identified and authenticated to the system. User accounts have several different components to them. First, there is the username. The password is next, followed by the access control information.

The following sections explore each of these components in more detail.

 

The Username

From the system's standpoint, the username is the answer to the question, "who are you?" As such, usernames have one major requirement — they must be unique. In other words, each user must have a username that is different from all other usernames on that system.

Because of this requirement, it is vital to determine — in advance — how usernames will be created. Otherwise, you will be in the position of being forced to react each time a new user requests an account.

What you need is a naming convention for your user accounts.

 

Naming Conventions

By creating a naming convention for usernames, you can save yourself a great deal of trouble. Instead of making up names as you go along (and finding it harder and harder to come up with a reasonable name), you do some work up-front and devise a convention that will be used for all subsequent user accounts. Your naming convention can be very simple, or the description alone could take several pages to document.

The exact nature of your naming convention should take several factors into account:

The size of your organization matters, as it dictates how many users your naming convention must support. For example, a very small organization might be able to have everyone use their first name. For a much larger organization this naming convention would not work.

An organization's structure can also have a bearing on the most appropriate naming convention. For organizations with a strictly-defined structure it might be appropriate to include elements of that structure in the naming convention. For example, you could include your organization's departmental codes as part of each username.

The overall nature of your organization may also mean that some naming conventions are more appropriate than others. An organization that deals with highly-classified data might choose a naming convention that does away with any personally-identifiable ties between the individual and their name. In such an organization, Maggie McOmie's username might be LUH3417.

Here are some naming conventions that other organizations have used:

Be aware that if your naming convention includes appending different data together to form a username, the potential exists that the result might be offensive or humorous. Therefore, even if you have automated username creation, it is wise to have some sort of review process in place.

One thing in common with the naming conventions described here is that it is possible that eventually there will be two individuals that, according to the naming convention, should be given the same username. This is known as a collision. Because each username must be unique, it is necessary to address the issue of collisions. The following section does this.

 

Dealing with Collisions

Collisions are a fact of life — no matter how you try, you will eventually find yourself with a collision on your hands. You must plan for collisions in your naming convention. There are several ways this can be done:

Having some method of resolving collisions is a necessary part of any naming convention. However, it does make it more difficult for someone outside the organization to accurately determine an individual's username. Therefore, the downside of most naming conventions is that the occasional misdirected email becomes more likely.

 

Dealing with Name Changes

If your organization uses a naming convention that is based on each user's name, it is a fact of life that you will eventually have to deal with name changes. The most common situation is one where a woman marries (or divorces) and changes her name, but this is not the only time a system administrator will be asked to change a username. Even if a person's actual name does not change, a change in username may from time to time be requested. The reasons can range from the user not being satisfied with the username to the user being a senior official in your organization and willing to use their influence to obtain a "more appropriate" username.

No matter what the reason, there are several issues to keep in mind when changing a username:

First and foremost, it is important to make sure that the new username is propagated to all systems where the original username was in use. Otherwise, any operating system function that relies on the username will work on some systems and not on others. Certain operating systems use access control techniques based on usernames; such systems are particularly vulnerable to problems stemming from a changed username.

Many operating systems use some sort of user identification number for most user-specific processing. To minimize the problems stemming from a username change, try to keep this identification number constant between the new and the old username. Failure to do so often results in a scenario where the user can no longer access files and other resources that they had previously owned under their original username.

If the user identification number must be changed, it is necessary to change the ownership for all files and user-specific resources to reflect the new user identification. This can be an error-prone process, as it seems that there is always something in some forgotten corner of a system that ends up being overlooked.

Issues related to email are probably the one area where a username change is the most difficult. The reason for this is that unless steps are taken to counteract it, email addressed to the old username will not be delivered to the new username.

Unfortunately, the issues surrounding the impact of username changes on email are multi-dimensional. At its most basic, a username change means that people no longer know the correct username for the person. At first glance, this might not seem to be such a problem — notify everyone in your organization of the change. But what about anyone outside of your organization that has sent this person email? How will they be notified? And what about mailing lists (both internal and external)? How can they be updated?

There is no easy answer to these questions. The best answer may be one of creating an email alias such that all email sent to the old username will automatically be forwarded to the new username. The user can then be urged to alert anyone who sends them email that their username has changed. As time goes on, fewer and fewer email messages will be delivered using the alias; eventually the alias can be removed.

While the use of aliases, at some level, perpetuates an incorrect assumption (that the user now known as esmith is still known as ejones), it is the only way to guarantee that email will reach the proper person.

If you use email aliases, be sure you take whatever steps are necessary to protect the old username from potential reuse. If you do not do this, and a new user receives the old username, email delivery (for either the original user or the new user) will be disrupted. The exact nature of the disruption depends on how email delivery is implemented on your operating system, but the two most likely symptoms are:

 

Passwords

If the username provides an answer to the question, "who are you?", the password is the response to the demand that inevitably follows:

"Prove it!"

In more formal terms, a password provides a means of proving the authenticity of a person's claim to be the user indicated by the username. The effectiveness of a password-based authentication scheme relies heavily on several aspects of the password:

Passwords that adequately address these issues are said to be strong, while those that fail to address one or more of these issues is said to be weak. Creating strong passwords is important for the security of the organization, as strong passwords are less likely to be discovered or guessed. There are two options available to enforce the use of strong passwords:

Creating passwords for all users ensures that the passwords are strong, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.

For these reasons, most system administrators prefer to have their users create their own passwords. However, a good system administrator takes steps to verify that the passwords are strong.

For guidelines on creating strong passwords, see the chapter titled Workstation Security in the Red Hat Linux Security Guide.

The need for passwords to be kept secret should an ingrained part of every system administrator's mindset. However, this point is often lost on many users. In fact, many users do not even understand the difference between usernames and passwords. Given this unfortunate fact of life, it is vital that some amount of user education be undertaken, so that your users understand that their password should be kept as secret as their paycheck.

Passwords should be as difficult as possible to guess. A strong password is one that an attacker would not be able to guess, even if the attacker knew the user well.

A brute-force attack on a password entails methodically trying (usually via a program known as a password-cracker) every possible combination of characters in the hopes that the proper password will eventually be found. A strong password should be constructed in such a way as to make the number of potential passwords that must be tested very large, forcing the attacker to take a long time searching for the password.

Strong and weak passwords are explored in more detail in the following sections.

 

Weak Passwords

As stated earlier, a weak password fails one of these three tests:

The following sections show how passwords can be weak.

 

Short Passwords

A password that is short is weak because it much more susceptible to a brute-force attack. To illustrate this, consider the following table, where the number of potential passwords that would have to be tested in a brute-force attack is shown. (The passwords are assumed to consist only of lower-case letters.)

 

1
Password LengthPotential Passwords
26
2 676
3 17,576
4 456,976
5 11,881,376
6 308,915,776

Table 6-1. Password Length Versus the Number of Potential Passwords

As you can see, the number of possible passwords increases dramatically as the length increases.

Even though this table ends at six characters, this should not be construed as recommending that six-character passwords are sufficiently long for good security. In general, the longer the password, the better.

 

Limited Character Set

The number of different characters that can comprise a password has a large impact on the ability of an attacker to conduct a brute-force attack. For example, instead of the 26 different characters that can be used in a lower-case-only password, what if we also used digits? That would mean each character in a password could be one of 36 characters instead of just one of 26. In the case of a six-character password, this increases the number of possible passwords from 308,915,776 to 2,176,782,336.

There is still more that can be done. If we also include mixed-case alphanumeric passwords (for those operating systems that support it), the number of possible six-character passwords increases to 56,800,235,584. Adding other characters (such as punctuation marks) further increases the number of possible passwords, making a brute-force attack that much more difficult.

However, one point to keep in mind is that not every attack against a password is a brute-force attack. The following sections describe other attributes that can make a weak password.

 

Recognizable Words

Many attacks against passwords are based on the fact that people are most comfortable with passwords they can remember. And for most people, passwords that are memorable are passwords that contain words. Therefore, most password attacks are dictionary-based. In other words, the attacker uses dictionaries of words in an attempt to find the word or words that comprise a password.

Many dictionary-based password attack programs use dictionaries from multiple languages. Therefore, you should not feel that you have a strong password just because you have used non-English words in your password.

 

Personal Information

Passwords that contain personal information (the name or birth date of a loved one, a pet, or a personal identification number) may or may not be picked up by a dictionary-based password attack. However, if the attacker knows you personally (or is sufficiently motivated to research your personal life), they might be able to guess your password with little or no difficulty.

In addition to dictionaries, many password-crackers also include common names, dates, and other such information in their search for passwords. Therefore, even if the attacker does not know that your dog is named Gracie, they could still find out that your password is "mydogisgracie", with a good password-cracker.

 

Simple Word Tricks

Using any of the previously discussed information as the basis for a password, but reversing the character order will not turn a weak password into a strong password. Most password-crackers perform such tricks on possible passwords. This includes substituting certain numbers for letters in common words. Here are some examples:

 

The Same Password for Multiple Systems

Even if you have a password that is strong, it is a bad idea to use the exact same password on more than one system. Obviously little can be done if the systems are configured to use a central authentication server of some kind, but in every other instance, different passwords should be used for each system.

 

Passwords on Paper

Another way to turn a strong password into a weak one is to write it down. By putting a password on paper, you no longer have a secrecy problem, you have a physical security problem — now keep a piece of paper secure. Therefore, writing down a password is never a good idea.

However, some organizations have a legitimate need for written passwords. For example, some organizations have written passwords as part of a procedure to recover from the loss of key personnel (such as system administrators). In these instances, the paper containing the passwords is stored in a physically-secure location that requires multiple people to cooperate in order to get access to the paper. Vaults with multiple locks and bank safe deposit boxes are often used.

Any organization that explores this method of storing passwords for emergency purposes should be aware that the existence of written passwords adds an element of risk to their systems' security, no matter how securely the written passwords may be stored. This is particularly true if it is generally known that the passwords are written down (and where they are stored).

Unfortunately, written passwords are often not part of a recovery plan and are not stored in a vault, but are passwords for ordinary users, and are stored in the following places:

None of these locations are proper places for a written password.

 

Strong Passwords

We have seen what weak passwords are like; the following sections describe features that all strong passwords possess.

 

Longer Passwords

The longer a password is, the less likely it is that a brute-force attack will succeed. Therefore, if your operating system supports it, set relatively large minimum password lengths for your users.

 

Expanded Character Set

Encourage the use of mixed-case, alphanumeric passwords, and strongly encourage the addition of at least one non-alphanumeric character to all passwords:

 

Memorable

A password is strong only if it can be remembered. However, being memorable and being easily guessed too often go hand-in-hand. Therefore, give your user community some tips on the creation of memorable passwords that cannot be easily guessed.

For example, take a favorite saying or phrase, and use the first letters of each word as the starting point in the creation of a new password. The result is memorable (because the phrase on which it is based is itself memorable), yet the result contains no words.

Keep in mind that just using the first letters of each word in a phrase is not sufficient to make a strong password. Always be sure to increase the password's character set by including mixed-case alphanumeric characters and at least one special character as well.

 

Password Aging

If at all possible, implement password aging at your organization. Password aging is a feature (available in many operating systems) that sets limits on the time that a given password will be considered valid. At the end of a password's lifetime, the user will be prompted to enter a new password, which can then be used until, it too, expires.

The key question regarding password aging that many system administrators face is that of the password lifetime. What should it be?

There are two diametrically-opposed issues at work with respect to password lifetime:

On one extreme, a password lifetime of 99 years would present very little (if any) user inconvenience. However, it would provide very little (if any) security enhancement.

On the other extreme, a password lifetime of 99 minutes would be a large inconvenience to your users. However, security would be greatly enhanced.

The idea is to find a balance between your users' desired for convenience and your organization's need for security. For most organizations, password lifetimes in the weeks-to-months range are most common.

 

Access Control Information

Along with a username and password, user accounts also contain access control information. This information takes on different forms according to the operating system being used. However, the types of information often include:

In some organizations, a user's access control information may never need to be touched. This is most often the case with standalone, personal workstations, for example. Other organizations, particularly those that make extensive use of network-wide resource sharing among different groups of users, require that a user's access control information be extensively modified.

The workload required to properly maintain your users' access control information varies according to how extensively your organization uses your operating system's access control features. While it is not a bad thing to rely so heavily on these features (in fact, it may be unavoidable), it does mean that your system environment will require more effort to maintain, and that every user account will have more ways in which it can be mis-configured.

Therefore, if your organization requires this kind of environment, you should make a point of documenting the exact steps required to create and correctly configure a user account. In fact, if there are different types of user accounts, you should document each one (creating a new finance user account, a new operations user account, etc.).

 

Managing Accounts and Resource Access Day-to-Day

As the old saying goes, the only constant is change. It is no different when dealing with your user community. People will come, people will go, and people will move from one set of responsibilities to another. Therefore, system administrators must be able to respond to the changes that are a normal part of day-to-day life in your organization.

 

New Hires

When a new person joins your organization, they are normally given access to various resources (depending on their responsibilities). They may be given a place to work, a phone, and a key to the front door.

They may also be given access to one or more of the computers in your organization. As a system administrator, it is your responsibility to see that this is done promptly and appropriately. How should you do this?

Before you can do anything, first be aware of the new person's arrival. This is handled differently in various organizations. Here are some possibilities:

Different organizations require different approaches. However it is done, it is vital that you have a highly-reliable process that can alert you to any account-related work that needs to be done.

 

Terminations

The fact that people will be leaving your organization is a given. Sometimes it will be under happy circumstances and sometimes it will be under unhappy circumstances. In either case, it is vital that you are made aware of the situation so that you can take the appropriate actions.

At the very least, the appropriate actions should include:

The top priority is to secure your systems against the newly-terminated user. This is particularly important if the user was terminated under conditions that could leave the user feeling malice toward your organization. However, even if the circumstances are not quite so dire, it is in your organization's best interest for you to quickly and reliably disable access by the newly-terminated person.

This indicates the need for a process that alerts you to all terminations — preferably even before the actual termination takes place. This implies that you should work with your organization's personnel department to ensure that you are alerted to any upcoming terminations.

When handling system "lock-downs" in response to terminations, proper timing is important. If the lock-down takes place after the termination process has been completed, there is the potential for unauthorized access by the newly-terminated person. On the other hand, if the lock-down takes place before the termination process has been initiated, it could alert the person to their impending termination, and make the process more difficult for all parties.

The termination process is usually initiated by a meeting between the person to be terminated, the person's manager, and a representative of your organization's personnel department. Therefore, putting a process in place that alerts you to the termination as this meeting starts ensures that the timing of the lock-down is appropriate.

Once access has been disabled, it is then time to make a backup copy of the newly-terminated person's files. This backup may be part of your organization's standard backups, or it may be a backup procedure dedicated to backing up old user accounts. Issues such as data retention regulations, preserving evidence in case of a wrongful termination lawsuit, and the like will play a part in determining the most appropriate way to handle backups.

In any case, a backup at this point is a good practice, as the next step (manager access to the newly-terminated person's files) may result in accidentally-deleted files. In such circumstances, having a current backup makes it possible to easily recover from any such accidents, making the process easier on the manager and you.

At this point, determine what access the newly-terminated person's manager requires to the person's files. Depending on your organization and the nature of the person's responsibilities, it might be that no access is required, or that access to everything will be necessary.

If the person used your systems for more than incidental email, it is likely that the manager will have to sift through the files, determine what must be kept, and what may be discarded. As this process concludes, it is likely that at least some of the files will be given to the person or persons taking over the newly-terminated person's responsibilities. Your assistance may be required in this final step of the process, or the manager may be in a position to handle this themselves. It all depends on the files and the nature of the work your organization undertakes.

 

Job Changes

Responding to requests to create accounts for new users and handling the sequence of events necessary to lock-down an account when a person is terminated are both relatively straightforward processes. However, it is not so clear-cut when a person changes responsibilities within your organization. Sometimes the person will require changes to their accounts and sometimes they will not.

There will be at least three people involved in making sure the user's account is appropriately reconfigured to match their new responsibilities:

Between the three of you, it should be possible to determine what must take place to cleanly close out the user's old responsibilities, and what must be done to prepare the user's account for their new responsibilities. In many ways, this process can be thought of as being equivalent to shutting down an existing user account and creating a new user account. In fact, some organizations do this for all changes in responsibility.

However, it is more likely that the user's account will be kept and modified as appropriate to support their new responsibilities. This approach means that carefully review the account to ensure that no resources or access privileges are left on the account, and that the account has the resources and privileges appropriate to the person's new responsibilities.

Further complicating the situation is the fact that often there is a transition period where the user performs tasks related to both sets of responsibilities. This is where the user's original and new manager can help you by giving you a time frame for this transition period.


 

Additional Resources

This section includes various resources that can be used to learn more about account and resource management, and the Red Hat Linux-specific subject matter discussed in this chapter.

 

Installed Documentation

The following resources are installed in the course of a typical Red Hat Linux installation and can help you learn more about the subject matter discussed in this chapter.

 

Useful Websites

 

Related Books

The following books discuss various issues related to account and resource management, and are good resources for Red Hat Linux system administrators.


 

User Account and Group Applications

There are two basic types of applications one can use when managing user accounts and groups on Red Hat Linux systems:

For detailed instructions on using User Manager, see the chapter titled User and Group Configuration in the Red Hat Linux Customization Guide.

While both the User Manager application and the command line utilities perform essentially the same task, the command line tools have the advantage of being scriptable and therefore, more easily automated.

The following table describes some of the more common command line tools used to create and manage users:

 

ApplicationFunction
/usr/sbin/useradd Adds user accounts. This tool is also used to specify primary and secondary group membership.
/usr/sbin/userdel Deletes user accounts.
/usr/sbin/usermod Edits account attributes including some functions related to password aging. For more fine-grained control, use the passwd command. usermod is also used to specify primary and secondary group membership.
passwd Sets passwords. Although primarily used to change a user's password, it also controls all aspects of password aging.
/usr/sbin/chpasswd Reads in a file consisting of username and password pairs, and updates each users' password accordingly.
chage Changes the user's password aging policies. The passwd command can also be used for this purpose.
chfn Changes the user's GECOS information.
chsh Changes the user's default shell.

Table 6-1. User Management Command Line Tools

The following table describes some of the more common command line tools used to create and manage groups:

 

ApplicationFunction
/usr/sbin/groupadd Adds groups, but does not assign users to those groups. The useradd and usermod programs should then be used to assign users to a given group.
/usr/sbin/groupdel Deletes groups.
/usr/sbin/groupmod Modifies group names or GIDs, but does not change group membership. The useradd and usermod programs should be used to assign users to a given group.
passwd Changes group membership and sets passwords to allow non-group members who know the group password to join the group. It is also used to specify group administrators.
/usr/sbin/grpck Checks the integrity of the /etc/group and /etc/gshadow files.

Table 6-2. Group Management Command Line Tools

The tools listed thus far provide system administrators great flexibility in controlling all aspects of user accounts and group membership. To learn more about how they work, refer to the man page for each. These applications do not, however, determine what resources these users and groups have control over. For this, the system administrator must use file permission applications.

 

File Permission Applications

Permissions for files, directories, and applications are an integral part of managing resources within an organization. The following table describes some of the more common command line tools used for this purpose.

 

ApplicationFunction
chgrp Changes which group owns a given file.
chmod Changes access permissions for a given file. It is also capable of assigning special permissions.
chown Changes a file's ownership (and can also change group).

Table 6-3. Permission Management Command Line Tools

It is also possible to alter these attributes in GNOME and KDE graphical environments by right-clicking on the desired object and selecting Properties. The next section will review what happens when an application is used to create user accounts and groups.


 

Files Controlling User Accounts and Groups

On Red Hat Linux, information about user accounts and groups are stored in several text files within the /etc/ directory. When a system administrator creates new user accounts, these files must either be edited by hand or applications must be used to make the necessary changes.

The following section document the files in the /etc/ directory that store user and group information under Red Hat Linux.

 

/etc/passwd

The /etc/passwd file is world-readable, and contains a list of users, each on a separate line. On each line is a seven field, colon delimited list which contains the following information:

Here is an example of a /etc/passwd entry:

 

root:x:0:0:root:/root:/bin/bash"

This line shows that the root user has a shadow password, as well as a UID and GID of 0. The root user has /root/ as a home directory, and uses /bin/bash for a shell.

 

/etc/shadow

The /etc/shadow file is readable only by the root user, and contains password and optional password aging information. As in the /etc/passwd file, each user's information is on a separate line. Each of these lines is a nine field, colon delimited list including the following information:

Here is an example line from /etc/shadow:

 

juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:11956:0:90:5:30:12197:

This line shows the following information for user juan:

 

/etc/group

The /etc/group is world-readable, and contains a list of groups, each on a separate line. Each line is a four field, colon delimited list including the following information:

Here is an example line from /etc/group:

 

general:x:502:juan,shelley,bob

This line shows that the general group is using shadow passwords, has a GID of 502, and that juan, shelley, and bob are members.

 

/etc/gshadow

The /etc/gshadow file is readable only by the root user, and contains an encrypted password for each group, as well as group membership and administrator information. Just as in the /etc/group file, each group's information is on a separate line. Each of these lines is a four field, colon delimited list including the following information:

Here is an example line from /etc/gshadow:

 

general:!!:shelley:juan,bob

This line shows that the general group has no password and does not allow non-members to join using the newgrp command. In addition, shelley is a group administrator, and juan and bob are regular, non-administrative members.

Since editing these files by hand raises the potential for syntax errors, it is recommended that the applications provided with Red Hat Linux for this purpose be used instead. The next section reviews the primary tools for performing these tasks.

 

Notes

GECOS stands for General Electric Comprehensive Operating System.


 

The Process of Creating User Accounts

When you create a user account using the User Manager application, you can manage all aspects of the user account. For detailed instructions on using User Manager, see the chapter titled User and Group Configuration in the Red Hat Linux Customization Guide. This section will highlight the multi-step user creation process necessary when using the command line tools.

There are two steps to creating a user with the command line tools included with Red Hat Linux:

  1. Issue the useradd command to create a locked user account.

  2. Unlock the account by issuing the passwd command to assign a password and set password aging guidelines.

The following steps illustrate what happens if the command /usr/sbin/useradd juan is issued on a system that has shadow passwords enabled:

  1. A new line for juan is created in /etc/passwd. The line has the following characteristics:

    • It begins with the username, juan.

    • There is an x for the password field indicating that the system is using shadow passwords.

    • A UID at or above 500 is created. (Under Red Hat Linux UIDs and GIDs below 500 are reserved for system use.)

    • A GID at or above 500 is created.

    • The optional GECOS information is left blank.

    • The home directory ( /home/juan/) is specified.

    • The default shell is set to /bin/bash.

  2. A new line for juan is created in /etc/shadow. The line has the following characteristics:

    • It begins with the username, juan.

    • Two exclamation points ( !!) appear in the password field of the /etc/shadow file, which locks the account.

    • The password is set to never expire.

  3. A new line for a group named juan is created in /etc/group. A group bearing the same name as a user is called a user private group.

    The line created in /etc/group has the following characteristics:

    • It begins with the group name, juan.

    • An x appears in the password field indicating that the system is using shadow group passwords.

    • The GID matches the one listed for user juan in /etc/passwd.

  4. A new line for a group named juan is created in /etc/gshadow. The line has the following characteristics:

    • It begins with the group name, juan.

    • Two exclamation points ( !!) appear in the password field of the /etc/gshadow file, which locks the group.

    • All other fields are blank.

  5. A directory for user juan is created in the /home/ directory. This directory is owned by user juan and group juan. However, it has read, write, and execute privileges only for the user juan. All other permissions are denied.

  6. The files within the /etc/skel/ directory (which contain default user settings) are copied into the new /home/juan/ directory.

At this point, a locked account called juan exists on the system. To activate it, the administrator must next assign a password to the account using the passwd command and, optionally, set password aging guidelines.

It is also possible to configure the account so that during the first log in, the user is asked to create a password. See the Section called New User Passwords.

 

Password Security

Creating strong passwords is important for the security of the organization. There are two options available to enforce the use of good passwords:

Creating passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows.

It also increases the risk of users writing their passwords down.

For these reasons, system administrators prefer to have the user create their own passwords. However, a good system administrator actively verifies that the passwords are good and, in some cases, forces users to change their passwords periodically through password aging.

For guidelines on how to create strong passwords and how to set password aging policies, see the chapter titled Workstation Security in the Red Hat Linux Security Guide.

 

New User Passwords

If passwords within an organization are created centrally by the administrator, adding new users to the organization means the administrators must configure the account so the user is asked to create a password when logging in for the first time.

To configure a user account in this manner, follow these steps:

  1. Create the user account using the useradd command. — At this point the account is created, but locked.

  2. Force immediate password expiration — To do this, type the following command:

     

    chage -d 0 
    

    This sets the value for the date the password was last changed to the epoch (January 1, 1970). This value forces immediate password expiration no matter what password aging policy, if any, is in place.

  3. Unlock the account — There are two common approaches to this. The administrator can assign an initial password:

     

    /usr/sbin/usermod -p "<password>"
    

    In the above command, replace <password> with the initial password.

    Or, the administrator can assign a null password:

     

    /usr/sbin/usermod -p ""
    

    While using a null password is convenient for both the user and the administrator, there is a slight risk that a third party can log in first and access the system. To minimize this threat, it is recommended that administrators verify that user is ready to log in when they unlock the account.

    In either case, upon initial log in, the user is prompted for a new password.


 

Managing User Resources

Creating user accounts is only part of a system administrator's job. Management of user resources is also essential. Therefore, three points must be considered:

The following sections briefly review each of these topics.

 

Who Can Access Shared Data

A user's access to a given application, file, or directory is determined by the permissions applied to that application, file, or directory.

In addition, it is often helpful if different permissions can be applied to different classes of users. For example, shared temporary storage should be capable of preventing the accidental (or malicious) deletions of a user's files by all other users, while still permitting the file's owner full access.

Another example is the access assigned to a user's home directory. Only the owner of the home directory should be able to create or view files there. Other users should be denied all access (unless the user wishes otherwise). This increases user privacy and prevents possible misappropriation of personal files.

But there are many situations where multiple users may need access to the same resources on a machine. In this case, careful creation of shared groups may be necessary.

 

Shared Groups and Data

As mentioned in the introduction, groups are logical constructs that can be used to cluster user accounts together for a specific purpose.

When managing users within an organization, it is wise to identify what data should be accessed by certain departments, what data should be denied to others, and what data should be shared by all. Determining this will aid in the creation of an appropriate group structure, along with permissions appropriate for the shared data.

For instance, assume that that the accounts receivable department must maintain a list of accounts that are delinquent on their payments. They must also share that list with the collections department. If both accounts receivable and collections personnel are made members of a group called accounts, this information can then be placed in a shared directory (owned by the accounts group) with group read and write permissions on the directory.

 

Determining Group Structure

Some of the challenges facing system administrators when creating shared groups are:

A common-sense approach to these questions is helpful. One possibility is to mirror your organization's structure when creating groups. For example, if there is a finance department, create a group called finance, and make all finance personnel members of that group. If the financial information is too sensitive for the company at large, but vital for senior officials within the organization, then grant the senior officials group-level permission to access the directories and data used by the finance department by adding all senior officials to the finance group.

It is also good to err on the side of caution when granting permissions to users. This way, sensitive information is less likely to fall into the wrong hands.

By approaching the creation of your organization's group structure in this manner, the need for access to shared data within the organization can be safely and effectively met.

 

Where Users Access Shared Data

When sharing data among users, it is a common practice to have a central server (or group of servers) that make certain directories available to other machines on the network. This way data is stored in one place; synchronizing data between multiple machines is not necessary.

Before taking this approach, first determine what systems are to access the centrally-stored data. As you do this, take note of the operating systems used by the systems. This information will have a bearing on your ability to implement such an approach, as your storage server must be capable of serving its data to each of the operating systems in use at your organization.

Unfortunately, once data is shared between multiple computers on a network, the potential for conflicts in file ownership can arise.

 

Global Ownership Issues

There are benefits if data is stored centrally and is accessed by multiple computers over a network. However, assume for a moment that each of those computers has a locally-maintained list of user accounts. What if the list of users on each of these systems are not consistent with the list of users on the central server? Even worse, what if the list of users on each of these systems are not even consistent with each other?

Much of this depends on how users and access permissions are implemented on each system, but in some cases it is possible that user A on one system may actually be known as user B on another system. This becomes a real problem when data is shared between these systems, as data that user A is allowed to access from one system can also be read by user B from another system.

For this reason, many organizations use some sort of central user database. This assures that there are no overlaps between user lists on different systems.

 

Home Directories

Another issue facing system administrators is whether or not users should have centrally-stored home directories.

The primary advantage of centralizing home directories on a network-attached server is that if a user logs into any machine on the network, they will be able to access the files in their home directory.

The disadvantage is that if the network goes down, users across the entire organization will be unable to get to their files. In some situations (such as organizations that make widespread use of laptops), having centralized home directories may not be desirable. But if it makes sense for your organization, deploying centralized home directories can make a system administrator's life much easier.

 

What Barriers Are in Place To Prevent Abuse of Resources

The careful organization of groups and assignment of permissions for shared resources is one of the most important things a system administrator can do to prevent resource abuse among users within an organization. In this way, those who should not have access to sensitive resources are denied access.

But no matter how your organization does things, the best guard against abuse of resources is always sustained vigilance on the part of the system administrator. Keeping your eyes open is often the only way to avoid having an unpleasant surprise waiting for you at your desk one morning.


 

Red Hat Linux-Specific Information

The following sections describe the various features specific to Red Hat Linux that relate to the administration of user accounts and associated resources.

 

User Accounts, Groups, and Permissions

Under Red Hat Linux, a user can log into the system and use any applications or files they are permitted to access after a normal user account is created. Red Hat Linux determines whether or not a user or group can access these resources based on the permissions assigned to them.

There are three different permissions for files, directories, and applications. These permissions are used to control the kinds of access allowed. Different one-character symbols are used to describe each permission in a directory listing. The following symbols are used:

A fourth symbol ( -) indicates that no access is permitted.

Each of the three permissions are assigned to three different categories of users. The categories are:

As stated earlier, it is possible to view the permissions for a file by invoking a long format listing with the command ls -l. For example, if the user juan creates an executable file named foo, the output of the command ls -l foo would look like this:

 

-rwxrwxr-x    1 juan     juan            0 Sep 26 12:25 foo

The permissions for this file are listed at the start of the line, beginning with rwx. This first set of symbols define owner access — in this example, the owner juan has full access, and may read, write, and execute the file. The next set of rwx symbols define group access (again, with full access), while the last set of symbols define the types of access permitted for all other users. Here, all other users may read and execute the file, but may not modify it in any way.

One important point to keep in mind regarding permissions and user accounts is that every application run on Red Hat Linux runs in the context of a specific user. Typically, this means that if user juan launches an application, the application runs using user juan's context. However, in some cases the application may need a more privileged level of access in order to accomplish a task. Such applications include those that edit system settings or log in users. For this reason, special permissions have been created.

There are three such special permissions within Red Hat Linux. They are:

 

Usernames and UIDs, Groups and GIDs

In Red Hat Linux, user account and group names are primarily for peoples' convenience. Internally, the system uses numeric identifiers. For users, this identifier is known as a UID, while for groups the identifier is known as a GID. Programs that make user or group information available to users translate the UID/GID values into their more human-readable counterparts.

UIDs and GIDs must be globally unique within your organization if you intend to share files and resources over a network. Otherwise, whatever access controls you put in place will fail to work properly, as they are based on UIDs and GIDs, not usernames and group names.

Specifically, if the /etc/passwd and /etc/group files on a file server and a user's workstation differ in the UIDs or GIDs they contain, improper application of permissions can lead to security issues.

For example, if user juan has a UID of 500 on a desktop computer, files juan creates on a file server will be created with owner UID 500. However, if user bob logs in locally to the file server (or even some other computer), and bob's account also has a UID of 500, bob will have full access to juan's files, and vice versa.

Therefore, UID and GID collisions are to be avoided at all costs.

There are two instances where the actual numeric value of a UID or GID has any specific meaning. A UID and GID of zero (0) are used for the root user, and are treated specially by Red Hat Linux — all access is automatically granted.

The second instance is that UIDs and GIDs below 500 are reserved for system use. Unlike UID/GID zero (0), UIDs and GIDs below 500 are not treated specially by Red Hat Linux. However, these UIDs/GIDs are never to be assigned to a user, as it is likely that some system component either currently uses or will use these UIDs/GIDs at some point in the future.

When new user accounts are added using the standard Red Hat Linux user creation tools, the new user accounts are assigned the first available UID and GID starting at 500. The next new user account is assigned UID/GID 501, followed by UID/GID 502, and so on.

A brief overview of the various user creation tools available under Red Hat Linux occurs later in this chapter. But before reviewing these tools, the next section reviews the files Red Hat Linux uses to define system accounts and groups.

 

Files Controlling User Accounts and Groups

On Red Hat Linux, information about user accounts and groups are stored in several text files within the /etc/ directory. When a system administrator creates new user accounts, these files must either be edited by hand or applications must be used to make the necessary changes.

The following section documents the files in the /etc/ directory that store user and group information under Red Hat Linux.

 

/etc/passwd

The /etc/passwd file is world-readable and contains a list of users, each on a separate line. On each line is a colon delimited list containing the following information:

Here is an example of a /etc/passwd entry:

 

root:x:0:0:root:/root:/bin/bash"

This line shows that the root user has a shadow password, as well as a UID and GID of 0. The root user has /root/ as a home directory, and uses /bin/bash for a shell.

 

/etc/shadow

Because the /etc/passwd file must be world-readable (the main reason being that this file is used to perform the translation from UID to username), there is a risk involved in storing everyone's password in /etc/passwd. True, the passwords are encrypted. However, it is possible to perform attacks against passwords if the encrypted password is available.

If a copy of /etc/passwd can be obtained by an attacker, an attack that can be carried out in secret becomes possible. Instead of risking detection by having to attempt an actual login with every potential password generated by password-cracker, an attacker can use a password cracker in the following manner:

The most dangerous aspect of this attack is that it can take place on a system far-removed from your organization. Because of this, the attacker can use the highest-performance hardware available, making it possible to go through massive numbers of passwords very quickly.

Therefore, the /etc/shadow file is readable only by the root user and contains password (and optional password aging information) for each user. As in the /etc/passwd file, each user's information is on a separate line. Each of these lines is a colon delimited list including the following information:

Here is an example line from /etc/shadow:

 

juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:11956:0:90:5:30:12197:

This line shows the following information for user juan:

 

/etc/group

The /etc/group file is world-readable and contains a list of groups, each on a separate line. Each line is a four field, colon delimited list including the following information:

Here is an example line from /etc/group:

 

general:x:502:juan,shelley,bob

This line shows that the general group is using shadow passwords, has a GID of 502, and that juan, shelley, and bob are members.

 

/etc/gshadow

The /etc/shadow file is readable only by the root user and contains an encrypted password for each group, as well as group membership and administrator information. Just as in the /etc/group file, each group's information is on a separate line. Each of these lines is a colon delimited list including the following information:

Here is an example line from /etc/shadow:

 

general:!!:shelley:juan,bob

This line shows that the general group has no password and does not allow non-members to join using the newgrp command. In addition, shelley is a group administrator, and juan and bob are regular, non-administrative members.

Since editing these files by hand raises the potential for syntax errors, it is recommended that the applications provided with Red Hat Linux for this purpose be used instead. The next section reviews the primary tools for performing these tasks.

 

User Account and Group Applications

There are two basic types of applications that can be used when managing user accounts and groups on Red Hat Linux systems:

For detailed instructions on using User Manager, see the chapter titled User and Group Configuration in the Red Hat Linux Customization Guide.

While both the User Manager application and the command line utilities perform essentially the same task, the command line tools have the advantage of being script-able and are therefore more easily automated.

The following table describes some of the more common command line tools used to create and manage user accounts and groups:

 

ApplicationFunction
/usr/sbin/useradd Adds user accounts. This tool is also used to specify primary and secondary group membership.
/usr/sbin/userdel Deletes user accounts.
/usr/sbin/usermod Edits account attributes including some functions related to password aging. For more fine-grained control, use the passwd command. usermod is also used to specify primary and secondary group membership.
passwd Sets passwords. Although primarily used to change a user's password, it also controls all aspects of password aging.
/usr/sbin/chpasswd Reads in a file consisting of username and password pairs, and updates each users' password accordingly.
chage Changes the user's password aging policies. The passwd command can also be used for this purpose.
chfn Changes the user's GECOS information.
chsh Changes the user's default shell.

Table 6-2. User Management Command Line Tools

The following table describes some of the more common command line tools used to create and manage groups:

 

ApplicationFunction
/usr/sbin/groupadd Adds groups, but does not assign users to those groups. The useradd and usermod programs should then be used to assign users to a given group.
/usr/sbin/groupdel Deletes groups.
/usr/sbin/groupmod Modifies group names or GIDs, but does not change group membership. The useradd and usermod programs should be used to assign users to a given group.
passwd Changes group membership and sets passwords to allow non-group members who know the group password to join the group. It is also used to specify group administrators.
/usr/sbin/grpck Checks the integrity of the /etc/group and /etc/gshadow files.

Table 6-3. Group Management Command Line Tools

The tools listed thus far provide system administrators great flexibility in controlling all aspects of user accounts and group membership. To learn more about how they work, refer to the man page for each. These applications do not, however, determine what resources these users and groups have control over. For this, the system administrator must use file permission applications.

 

File Permission Applications

Permissions for files, directories, and applications are an integral part of managing resources within an organization. The following table describes some of the more common command line tools used for this purpose.

 

ApplicationFunction
chgrp Changes which group owns a given file.
chmod Changes access permissions for a given file. It is also capable of assigning special permissions.
chown Changes a file's ownership (and can also change group).

Table 6-4. Permission Management Command Line Tools

It is also possible to alter these attributes in the GNOME and KDE graphical environments by right-clicking on the desired object and selecting Properties.

GECOS stands for General Electric Comprehensive Operating Supervisor. This field was used at Bell Labs, in the original UNIX implementation. The lab had many different computers, including one running GECOS. This field was used to store information when the UNIX system sent batch and print jobs to the GECOS system.


 

Home