Chapter 6. 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.
6.1. 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.
6.1.1. 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.
6.1.1.1. 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
The structure of your organization
The nature of your organization
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:
First name (john, paul, george, etc.)
Last name (smith, jones, brown, etc.)
First initial, followed by last name (jsmith, pjones, gbrown, etc.
Department code followed by user's last name (029smith, 454jones, 191brown, etc.)
 | Tip |
|---|---|
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.
6.1.1.1.1. 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:
Adding sequence numbers to the colliding username (smith, smith1, smith2, etc.)
Adding user-specific data to the colliding username (smith, esmith, eksmith, etc.)
Adding organizational information to the colliding username (smith, smith029, smith454, etc.)
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.
6.1.1.2. 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:
Make the change to all affected systems
Keep any underlying user identification constant
Change the ownership of all files and other user-specific resources (if necessary)
Handle email-related issues
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.
 | Important |
|---|---|
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:
|
6.1.2. 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:
The secrecy of the password
The resistance of the password to guessing
The resistance of the password to a brute-force attack
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:
The system administrator can create passwords for all users.
The system administrator can let the users create their own passwords, while verifying that the passwords are acceptably strong.
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.
6.1.2.1. Weak Passwords
As stated earlier, a weak password fails one of these three tests:
It is secret
It is resistant to being guessed
It is resistant to a brute-force attack
The following sections show how passwords can be weak.
6.1.2.1.1. 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.)
| Password Length | Potential Passwords |
|---|---|
| 1 | 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.
 | Note |
|---|---|
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. |
6.1.2.1.2. 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.
6.1.2.1.3. 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.
 | Note |
|---|---|
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. |
6.1.2.1.4. 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.
6.1.2.1.5. 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:
drowssaPdaB1
R3allyP00r
6.1.2.1.6. 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.
6.1.2.1.7. 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 you must 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:
In a desk drawer (locked or unlocked)
Below a keyboard
In a wallet
Taped to the side of a monitor
None of these locations are proper places for a written password.
6.1.2.2. Strong Passwords
We have seen what weak passwords are like; the following sections describe features that all strong passwords possess.
6.1.2.2.1. 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.
6.1.2.2.2. 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:
t1Te-Bf,te
Lb@lbhom
6.1.2.2.3. 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.
| Note |
|---|---|
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. |
6.1.2.3. 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:
User convenience
Security
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.
6.1.3. 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:
System-wide user-specific identification
System-wide group-specific identification
Lists of additional groups/capabilities to which the user is a member
Default access information to be applied to all user-created files and resources
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.).
6.1.4. 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.
6.1.4.1. 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, you must first be aware of the new person's arrival. This is handled differently in various organizations. Here are some possibilities:
Create a procedure where your organization's personnel department notifies you when a new person arrives.
Create a form that the person's supervisor can fill out and use to request an account for the new person.
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.
6.1.4.2. 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:
Disabling the user's access to all systems and related resources (usually by changing/locking the user's password)
Backing up the user's files, in case they contain something that is needed at a later time
Coordinating access to the user's files by the user's manager
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.
| Tip |
|---|---|
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, you must 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.
6.1.4.3. 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:
You
The user's original manager
The user's new manager
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 you must 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.