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.
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.
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 passwdSun’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.bigcoComputers 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.
On Mac OS X systems running NetInfo, you can view the account database using the command:
% nidump passwd . Systems that are configured for RADIUS generally do not make it possible to access the entire account database at once.
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[46] [nscd] that caches LDAP responses locally to reduce the number of network authentications required). LDAP is covered in detail in Chapter 14.
[46] Don’t confuse this “name service” with Domain Name Service (DNS). Although nscd can cache DNS lookups of hostnames, its primary strength is its ability to cache lookups of users, groups, and passwords made through local files, NIS, NIS+, LDAP, and other authentication systems.
Get Practical UNIX and Internet Security, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
