4.4 Network Account and Authorization Systems
These days, many organizations have moved away from large
time-sharing computers and invested in large client/server networks
containing many servers and dozens or hundreds of workstations. These
systems are usually set up so that any user can make use of any
workstation in a group or in the entire organization. When these
systems are in use, every user effectively has an account on every
workstation. These systems provide for automatic account creation and
password synchronization between some or many computer systems.
When you are working with a large, distributed system, it is not
practical to ensure that every computer has the same
/etc/passwd file. For
this reason, there are now several different commercial systems
available that make the information traditionally stored in the
/etc/passwd file available over a network.
4.4.1 Using Network Authorization Systems
Five
network authorization systems in use today are:
Sun Microsystems' Network
Information System (NIS) and NIS+.
MIT Kerberos, which is now part of the OSF
Distributed Computing Environment (DCE) and
Microsoft's Windows XP. Kerberos clients are also
included with
Solaris, Linux, and several other Unix
versions.
NetInfo,
originally developed by NeXT Computer, now part of Mac OS X.
RADIUS, the Remote
Authentication Dial-In User Service. Traditionally, RADIUS has been
used by many ISPs to provide for authentication of dialup users. It
has been extended to provide authentication for other devices (e.g.,
routers) and for password synchronization in a Unix environment.
Authentication systems that store account information in a
Lightweight Directory
Access Protocol (LDAP) server.
These systems all take the information that is usually stored in each
workstation's /etc/passwd file
and store it in one or more network servers. Some systems use the
network-based account to supersede the accounts on the local system;
others augment the local accounts with network-based accounts.
Some of these systems provide for multiple servers or backup caching,
should the primary server be unavailable. Others do not, and instead
create a single point of failure for the entire network.
At some sites, administrators prefer not to use network database
management systems. Instead, each computer might have its own
accounts. Alternatively, one computer might be regarded as the
"master computer," and that
computer's /etc/passwd and
/etc/shadow files are then distributed to other
computers using scp, rdist,
or a similar system. There are several reasons that an administrator
might make such a decision.
Managing a network-based authentication system is often considerably
more complex than managing accounts on a single system.
Unless redundant servers are provided, a crashed authentication
server or failed network segment can negatively impact a
disproportionately large number of users.
The administrator might be fearful that the central authentication
server could be compromised, which would allow an attacker to create
an account on any computer that the attacker wished.
The drawback to this approach is that it often requires the
administrator to intervene to change a user password or shell entry.
In most cases, the energy spent developing and fielding custom
solutions would be better spent mastering systems that are already in
existence and, in many cases, preinstalled on most Unix systems.
|
Because there are so many different ways to access the information
that has traditionally been stored in the
/etc/passwd file, throughout this book we will
simply use the phrase "password
file" or
"/etc/passwd "
as a shorthand for the multitude of different systems.
|
|
4.4.2 Viewing Accounts in the Network Database
If you are using one of
these systems and wish to retrieve the contents of the password
database, you cannot simply cat the
/etc/passwd file. Instead, you must use a
command that is specific to your system to view the account database.
Sun's NIS service
supplements the information stored in the
workstations' own files. If you are using NIS and
you wish to get a list of every user account, you would use the
following command:
% cat /etc/passwd;ypcat passwd
4.4.2.1 NIS and NIS+
Sun's NIS+ service
can be configured to supplement or substitute its user account
entries for those entries in the /etc/passwd
file, depending on the contents of the
/etc/nsswitch.conf file. If you are using a
system that runs NIS+, you should use the
niscat command and specify your NIS+ domain.
For example:
% niscat -o passwd.bigco
4.4.2.2 Kerboros DCE
Computers that are using DCE use an
encrypted network database system as an alternative to encrypted
passwords and /etc/passwd files. However, to
maintain compatibility, some of them have programs that run on a
regular basis to create a local /etc/passwd
file. You should check your manuals for information about your
specific system.
4.4.2.3 NetInfo
On Mac OS X systems running NetInfo, you can view the account
database using the command:
% nidump passwd .
|
Note again that Mac OS X's system exposes the
encrypted password field when the
nidump command is used. Thus, although
Mac OS X uses the FreeBSD
master.passwd file, it still exposes the entire
password database to anyone who wants it. This happens whether or not
a network server is in use.
|
|
4.4.2.4 RADIUS
Systems that are configured for RADIUS generally do not make it
possible to access the entire account database at once.
4.4.2.5 LDAP
LDAP is used to build a true network authentication system; rather
than create local /etc/passwd entries, systems
that use LDAP for authentication are configured to check logins
against the network's LDAP server each time (though
some configurations do include a name service-caching
daemon
[nscd] that caches LDAP responses locally to
reduce the number of network authentications required). LDAP is
covered in detail in Chapter 14.
|