Chapter 5
Account Management
After the system boots into a multiuser state, this is where it
all starts: You cannot get into a system without an account. You all know by
now that this is the way of UNIX. Other operating systems have recently adopted
this capability. You also know that there are user accounts and root accounts,
both with different levels of access.
As a UNIX system
administrator, you know the seven fields that make up the password file, so
I won't discuss those here. (However, there is a growing problem with potential
intermediate and senior administrators who, during job interviews, are not able
to recite the simple seven fields of a password file. I'll discuss that
in greater detail in Chapter 10, "System Administration:
The Occupation.") Although you might know the purpose of each field,
how they are used is another story entirely. This chapter covers, among other
things, the various ways the password fields can be set up and the things to
watch out for.
In addition, there are ways to manipulate user accounts that are
unobtrusive to your user community. There are new and perhaps forgotten ways
of adding, changing, disabling, and even removing accounts. This chapter covers
various techniques to enhance user environments for you and your user. Other
topics in this chapter talk about uses for your startup files, killing accounts,
and working in various shells.
5.1 User Account Names
5.1.1 Description
There are many user account names to choose from and standards
to follow.
Example One: Cryptic Standard
In the early days of mainframes, the first online services, and
DOD projects, user account names were often cryptic and difficult to remember
or use. No matter what the account name was, though, it was unique, well structured,
and documented for control or security reasons. Some of these IDs took the form
of
- Project titles with employee numbers-- atlas0254 or
cargo660
- A fixed set of characters followed by a hexadecimal-based
number-- yqq2dfd or dls302a.
- Cryptic alphanumeric-- a05ft3sd or 04598277.
These accounts never took the form or had any part of the users
name within it. These are still used today, more often in highly secure environments
where the risk of penetration is high.
Example Two: Abbreviated Usernames
As UNIX gained in momentum, naming conventions were originally
grandfathered from the mainframes and old standards. When email, bulletin boards,
and other functions, protocols, and sites began emerging on the Internet, user
accounts began to include the user's actual name or site name as the account
name. People didn't want to hide behind a cryptic account. They wanted
something easy to remember and more readable. Although the limitation of eight
characters felt limiting, many users (who were the administrators) began adopting
various new forms for naming conventions:
- First initial, followed by the middle initial, followed by
the remaining letters of the last name to total no more than eight characters.
So the name John Paul Johnston becomes jpjohnst. Mary Kay Lipton has
the ID mklipton. If a person did not have a middle initial an x
replaces the middle initial.
- First name, middle initial, last initial, up to eight characters.
Steve Allan Mitchell would have steveam for an account name. For small
companies this worked fine, but in larger installation there is more of a
chance for duplicate user IDs. Steve Adam Monroe would have the same account
name, steveam.
-
Abbreviations--UNIX is often known as the abbreviated operating
system with so many of the commands being so short in name. Many admins
and users alike continue to follow the pattern of UNIX and set short names
for a naming standard. Some are also just looking for the speed in typing
three letters for their account names. For this reason, many choose to have
their initials as their account name.
Example Three: Application Names
Many names are commonly used to depict what applications are running
on the system. This still holds true today. When applications are installed
on a system, they often create an account specific for that application to run
daemons and other routines. This is sometimes required by the vendor; other
times it can be done for convenience. This can pose somewhat of a security threat
to the system. For an intruder, these names can be targeted first for hacking.
Passwords set on these accounts are often easy to remember because they are
shared with others. If vendors do the install, they usually make the password
simple and able to be cracked by a simple password-cracking program. Some applications
or daemons are locked to the account name when they are executed. Check with
the vendor before changing the name.
Reason
Every organization has a way of dictating the standard for user
accounts. You need to be aware of all the possibilities that work best in your
environment if you are the one that gets to set the standard.
Real World Experience
As you can see, there really is no global standard. Most companies
are adopting the first initial, middle initial, and the rest of the last name
as the standard user ID. It all depends on the environment. Most programming
and development groups use code words or real names, some aerospace organizations
still like cryptic IDs such as in the mainframe days, and the rest sometimes
use some adaptations of the user's name or handles.
In
development environments where there is a lot of creative freedom in the organization,
let the user choose her own name if you can. Doing so also gives off a good
first impression about yourself to the user. She will perceive that you are
willing to work with her and not against her in the future. If you have a structured
naming standard and the user doesn't feel comfortable with the name, let
her know what other IDs have been used in the past and how fortunate she really
is. If she is persistent on a more friendly account name, let her know that
you intend to raise the issue with your management, because she feels so strongly
about this issue.
Users know today that the IDs given to them are the ones they
will have for the life of their position with the company, which could be many
years. You might be able to compromise with the user by providing a friendly
email address if you have access to the email system. The standard for the beginning
of an email address would typically begin with the account ID of the user. Today,
standards are starting to emerge within companies that includes the first and
last names of the user separated by either a period or a underscore for the
format of an email address.
|
Warning - If an account needs
to be disabled, never place a pound sign ( #)
in front of the account name. In some flavors, UNIX accepts metacharacters
as part of the user name and see this as just another account name. A
pound sign does not denote the line as being a comment. Disabling
accounts should be done from the password field.
|
© Copyright Macmillan USA. All rights
reserved.
Previous
Section