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:
The new user never receives any email — it all goes
to the original user.
The original user suddenly stops receiving any email
— it all goes to the new user.
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.
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:
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.
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:
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 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.
