|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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.
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.
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 are to be created. Otherwise, you may
find yourself 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.
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
to 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.)
-
Last name, followed by department code (smith029, jones454,
brown191, 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.
Collisions are a fact of life — no matter how you try, you
will eventually find yourself dealing with a collision. 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.
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. 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 may 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 should 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 is automatically 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
reaches 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) may 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:
|
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 Enterprise Linux Security
Guide.
The need for passwords to be kept secret should be 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 correct 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.
As stated earlier, a weak password fails one of these three
tests:
The following sections show how passwords can be weak.
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.
|
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.
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.
|
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.
Using any of the previously discussed information as the basis
for a password, but reversing the character order does 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:
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.
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:
None of these locations are proper places for a written
password.
We have seen what weak passwords are like; the following
sections describe features that all strong passwords possess.
The longer a password is, the less likely it is that a
brute-force attack may succeed. Therefore, if your operating system
supports it, set relatively large minimum password lengths for your
users.
Encourage the use of mixed-case, alphanumeric passwords, and
strongly encourage the addition of at least one non-alphanumeric
character to all passwords:
A password is strong only if it can be remembered. However,
being memorable and being easily guessed too often go together.
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.
|
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 is considered valid. At the end of a password's lifetime,
the user is 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.
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 may require more effort to maintain, and that every
user account can 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.).
As the old saying goes, the only constant is change. It is no
different when dealing with your user community. People come,
people go, and people 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.
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.
The fact that people will be leaving your organization is a
given. Sometimes it may be under happy circumstances and sometimes
it may 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 all 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 has to sift through the files,
determine what must be kept, and what may be discarded. As this
process concludes, at least some of the files may 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.
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 may
require changes to their accounts and sometimes they may 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 you must carefully review the account to
ensure that it has only those 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.
|
|
|
