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.
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.
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 aids 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.
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 be cautious 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.
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, you must 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 has 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.
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.
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.
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.
