On older Unix systems passwords were stored in the /etc/password file, but they were moved to the /etc/shadow file (which is readable only by the root user) on more recent systems to prevent non-root users from having access to the encrypted form of a user’s password, for security reasons. Most Linux systems that use local authentication store passwords in the /etc/shadow file, though some still use /etc/passwd as an artifact or for compliance with aging applications. If the second colon-separated field in each entry in /etc/passwd contains an x, your system is using the /etc/shadow file to hold password information. If you see other characters between the first and second colons, your system is still storing its password information in the /etc/passwd file.

To quickly disable accounts on a Linux file server or on a user’s desktop machine, bring up /etc/shadow in a text editor and insert an asterisk (*) as the first character in the second field of the file (after the first colon), which is where the password is stored. This prevents subsequent logins but leaves the existing password intact. If circumstances reverse themselves and you’re asked to re-enable the user’s account, you can simply remove the asterisk to re-enable logins with the existing password. This is similar to the approach taken by the usermod -L user command, which inserts an exclamation mark (!) at the beginning of a user’s password entry to lock out that user. Actually, if your system provides the usermod command, you can just as easily use this command to disable an account, as long as /usr/sbin is in your PATH—it’s good to know how the command really works, though.

You never want to remove a user’s data until it has been safely backed up, so userdel -r user is the wrong command to use when you simply need to lock out a user. Removing an existing user account with the userdel command also often leaves you open to reusing the old user ID (UID) the next time you create an account, which should be against IT policy for security and privacy reasons.

Reusing UIDs is a bad idea because if a new account is created with a UID that previously existed on your system, the new user will own any files still on the system that were owned by the previous user. This most commonly occurs with email stored in system directories outside the user’s home directory, but such files can exist anywhere the previous user had write privileges. This can also cause a problem if files or directories owned by the previous user are restored from backups for some reason. Adopting a policy of not reusing UIDs prevents users from “accidentally” getting rights to files to which they shouldn’t really have access.

If your site uses a distributed authentication mechanism such as LDAP (the Lightweight Directory Access protocol) or NIS (the Network Information Service, originally designed by Sun Microsystems for use with the Network File System), quickly disabling an account is slightly more difficult, but it’s even more important that you be able to do so. If you are using distributed authentication, until the account is disabled, a user has access to all the machines at your site that share this authentication mechanism.

Systems that use NIS for authentication rely on centralized password and shadow files that are distributed to NIS clients by an NIS server. Many NIS systems store password information directly in the NIS password file (/var/yp/ypetc/passwd), because using NIS to share shadow password files (/var/yp/ypetc/shadow) largely defeats the security implied by the shadow file. On systems using local authentication, only the root user can read the /etc/shadow file—but on NIS systems, any user who can listen to the NIS server can see the shadow file.

To quickly disable a user’s account on systems that use NIS, you can directly edit the NIS master of the password or shadow file in exactly the same way that you edited the local copy in the previous section of this hack, putting an asterisk in front of the password entry for the specified user. The NIS masters of these files are stored in the directory /var/yp/ypetc on your NIS server. If the second colon-separated field in each entry in /var/yp/ypetc/passwd contains an x, your system is using the /var/yp/ypetc/shadow file to store password information. If you see other characters between the first and second colons, your system is still storing password information in /var/yp/ypetc/passwd.

Once you’ve modified the /var/yp/ypetc/passwd or /var/yp/ypetc/shadow file, you must push it to all NIS clients by changing directory to the /var/yp directory and using the make command:

	# cd /var/yp;make

You can, of course, always change an NIS user’s password by executing the yppasswd user command, but if you need to re-enable the account you will have to work with the user to reset the password.

LDAP is a much more powerful distributed technology than NIS, because it provides a central source from which many different applications can retrieve many different types of information. As discussed in “Centralize Logins with LDAP” [Hack #6] , LDAP information directories, also known as databases, provide a great solution for a central, enterprise-wide source for login, password, and other per-user account information. However, because sites that use LDAP for authentication do not use the standard password or shadow files to hold password information, you can only disable LDAP accounts by changing the information in the LDAP database. You can disable a user account either by changing information about a specific account record (known as “attributes”) in the database, by changing the access control list (ACL) on the information about the account so that the user no longer has access to it, or by directly changing the user’s password in the database.

Unless you are completely familiar with the schemas used in your LDAP database, disabling an account by changing its password is the fastest and easiest method. This doesn’t require that you remember every characteristic of your LDAP user/account scheme, and it can be done using the ldappasswd command. To change a user’s password when you are using LDAP authentication, become the root user, run this command, and supply a new password when prompted to do so:

	# ldappasswd–l user

PAMs are shared library modules that are automatically loaded by applications that were compiled with the primary Linux-PAM authentication library. Applications that use PAMs (or PAM modules, are they’re sometimes called) are typically referred to as PAM-aware applications.

PAMs satisfy different parts of the authentication requirements for PAM-aware applications, much like reusable code and libraries do for applications in general. For example, a PAM-aware version of the login program can invoke a variety of PAMs that check things such as whether the user logging in as root is on a terminal listed as a secure terminal, whether users are allowed to log in on the system at the moment, and other similar authentication requirements. Because PAMs are shared library modules, a PAM-aware version of the rsh program can reuse the same “are users allowed to log in on the system now?” PAM as the PAM-aware version of login, but then apply other rules that are more relevant to rsh than to login. PAM modules themselves are now typically stored in the directory /lib/security, though some older Linux distributions stored PAMs in /usr/lib/security.

The PAMs used by different PAM-aware applications are defined in one of two ways. In modern PAM implementations, they are controlled by application-specific configuration files found in the directory /etc/pam.d. In older PAM implementations, all PAM modules used by the applications on a system were defined in a single central configuration file, /etc/pam.conf. The older approach is still supported, but it’s deprecated—to maintain backward compatibility while encouraging the modern approach, the contents of the directory /etc/pam.d are used instead of the /etc/pam.conf file if both exist on your system. This hack focuses on PAM configuration files in /etc/pam.d, since that’s the way PAMs are used on most modern systems.

Each PAM configuration file in /etc/pam.d has the same name as the PAM-aware application or service it is associated with and contains the PAM rules used during its authentication process. The name of the configuration file to use is derived from the first parameter passed to the Linux-PAM library’s pam_start() function, which is the name of the service that is being authenticated (often the same as the name of the application, for convenience’s sake). These files can also contain comments—any characters on a line that follow the traditional hash mark (#) are interpreted as a comment.

Each non-comment line in one of the files in /etc/pam.d defines how a single PAM module is used as part of the authentication process for the associated application or service. Each of these files can contain four fields separated by whitespace, the first three of which are mandatory. These fields have the following meaning and content:

Well, that was mind-numbing but necessary reference information. To see all this in action, let’s look at an example.

The configuration file for the PAMs used by the login program is the file /etc/pam.d/login. On a Red Hat system of recent vintage, this file contains the following entries:

	#%PAM-1.0
	auth		required	pam_securetty.so
	auth		required	pam_stack.so service=system-auth
	auth		required	pam_nologin.so
	account		required	pam_stack.so service=system-auth
	password	required	pam_stack.so service=system-auth
	session		required	pam_stack.so service=system-auth
	session		optional	pam_console.so

The first line is a comment that identifies this PAM as conforming to the PAM 1.0 specification.

The second, third, and fourth lines define the auth (authentication) requirements for system logins, all of which must succeed because they are identified as required. The second line invokes the PAM module pam_securetty.so to check whether the user is logged in on a secure terminal, as defined in the file /etc/securetty. The third line invokes the pam_stack.so PAM module, a clever module used primarily on Red Hat–inspired systems that enables you to call the entire set of PAM requirements defined for a different service or application (and thus described in a separate file by that name in /etc/pam.d). In this case it calls the set (stack) of requirements defined for the system-auth service. We’ll look at that later—for now, it’s sufficient to know that the authentication requirements specified in that file must be satisfied. Finally, to wrap up the auth module-type entries for the login program, the fourth line invokes the pam_nologin.so PAM module to check whether logins are allowed on the system at the current time.

The fifth line in this file identifies the requirements for the account module-type, which in this case uses the pam_stack.so PAM module to verify that the set of requirements for the system-auth service have been satisfied.

Similarly, the sixth line in this file identifies the requirements for the password module-type, which also uses the pam_stack.so PAM module to verify that the set of requirements for the system-auth service have been satisfied.

Finally, the seventh and eighth lines in this file identify session requirements for the login program. The seventh line uses the familiar pam_stack.so PAM module to verify that the set of requirements for the system-auth service were satisfied. The eighth line in this file defines an optional requirement that the user be running on the console. If this module succeeds, the user is granted any additional privileges associated with this PAM module. If this module fails, authentication succeeds as long as the previous required modules have completed successfully, but the user doesn’t get the bonus privileges.

Now let’s look at the /etc/pam.d/system-auth file on the same system, which contains the following:

	#%PAM-1.0
	# This file is auto-generated.
	# User changes will be destroyed the next time authconfig is run.
	auth		required	/lib/security/pam_env.so
	auth		sufficient /lib/security/pam_unix.so likeauth nullok
	auth		required   /lib/security/pam_deny.so
	account		required   /lib/security/pam_unix.so
	password	required   /lib/security/pam_cracklib.so retry=3 type=
	password	sufficient /lib/security/pam_unix.so nullok use_authtok md5
				shadow
	password	required   /lib/security/pam_deny.so
	session		required   /lib/security/pam_limits.so
	session		required   /lib/security/pam_unix.so

Now that you grok PAM configuration files, you can see that the auth module-type first requires that the pam_env.so module succeed, then tries the pam_unix.so module, which is a generic module that can perform auth, account, password, and session functions (depending on how it is called). When called for the auth module-type, it verifies a user’s identity, sets credentials if successful, and so on. If this module succeeds, the following required entry for the pam_deny.so module isn’t executed. If the pam_unix.so module fails, pam_deny.so executes, which returns a failure code to ensure that the specified module-type will fail. In our login example, where another auth request (for pam_nologin.so) follows the invocation of the contents of the system-auth PAM stack, that auth request is executed, but its value isn’t important because pam_deny.so is required and has already indicated failure.

Next, the account module-type requires that the pam_unix.so module succeed—in this case, pam_unix.so provides default account checks.

Following the account check, the first password module-type line specifies that pam_cracklib.so be used when setting passwords to select a password that isn’t easily cracked, based on the contents of a database of easily cracked passwords (/usr/lib/cracklib_dict.pwd on Red Hat systems). Arguments to this module give the user three chances to select a password (by passing the argument retry=3) and specify that this password isn’t for any specific type of authentication, such as LDAP or NIS (by passing a null name using the type= argument). If this module succeeds, the second password module-type line invokes the standard pam_unix.so module, with arguments specifying that null passwords are acceptable but can’t be set by users (nullok), not to prompt for a password but to use any password that succeeded in a previous PAM of module-type password (use_authtok), that passwords use md5 hashing by default (md5), and that the system uses the /etc/shadow file to hold passwords (shadow). If this module fails, the user is denied access to the application or service that invoked the system-auth service through the next line, which invokes the pam_deny.so module to ensure failure of the password auth-type.

Finally, the session checks set system limits using the pam_limits.so module, which provides functions to initiate and terminate sessions.

If you need to take a few aspirin after parsing each entry in these files, join the club. But even though it’s a pain, security is one of any sysadmin’s most important responsibilities. If it’s any consolation, think how complex the code to implement all of this would have been without the flexibility that PAMs provide!

The text-format files in /etc/pam.d control the PAMs associated with each authentication-aware application or service. Some of these PAMs themselves use optional configuration files to further refine their behavior. The configuration files for individual PAMs are located in the directory /etc/security. Though these files must exist, they do not need to contain any useful information—they are there in case you want to take advantage of the advanced configuration options that they provide. Here is a list of the files in this directory that are found on a variety of Linux systems:

Applications that use PAMs are very powerful, and correct configuration is very important. However, the Linux-PAM library does provide a default configuration file for any applications and services that do not have their own configuration files. This is the file /etc/pam.d/other. Since a missing configuration file generally indicates a misconfigured system (or that someone has imported a PAM-aware binary without thinking things through), the /etc/pam.d/other file implements extremely paranoid security, as in the following example:

	#%PAM-1.0
	auth	 required	pam_deny.so
	account	 required	pam_deny.so
	password required	pam_deny.so
	session	 required	pam_deny.so

In this example, any request for any module-type that falls through to this PAM configuration file will return a failure code. A slightly more useful version of this file is the following:

	#%PAM-1.0
	auth	 required	pam_deny.so
	auth	 required	pam_warn.so
	account	 required	pam_deny.so
	account	 required	pam_warn.so
	password required	pam_deny.so
	password required	pam_warn.so
	session	 required	pam_deny.so
	session	 required	pam_warn.so

Because subsequent required entries for a given module-type are still executed, each module-type entry first executes the pam_deny.so PAM, which denies access to the requested service, and then also executes the pam_warn.so PAM, which logs a warning message to the system log.

To integrate Windows domain and Linux authentication, you’ll need to have the PAM, samba-winbind, and smb-client packages installed on your system. The core pieces of software that you’ll need are the daemon that enables you to communicate with a Windows domain controller, known as the winbindd daemon (usually installed as /usr/sbin/winbindd), a correctly configured /etc/samba/smb.conf file (used by the winbind daemon to obtain information about your domain and domain controller), and the PAM for domain authentication through this daemon (/lib/security/pam_winbind.so). The winbindd daemon and the pam-winbind.so module are both provided in the samba-winbind package, though to use the PAM you must have the PAM package installed and working on your system. The current versions of these packages at the time this book was written were pam-0.78-8, samba-winbind-3.0.13-1.1, and samba-client-3.0.13-1.1.

Of course, if your environment has enough Windows dependencies to make you want to authenticate your Linux boxes using Windows, you’re probably already using Samba to access your Windows shares from your Linux system or your Linux filesystems from your Windows systems. Nowadays, most Linux systems come with Samba installed. To get complete support for Windows domain authentication, you’ll want to make sure your system is running Samba 3.x or better. If you’re using a package manager, you can run the command rpm -q packagename to find out which version of each of these is installed on your system.

If you’re missing any of the packages that you need or want, you can either consult your favorite package repository (RPMBone and RPMFind.net come to mind) to find a prebuilt package for your system, or download the complete Samba source code from http://www.samba.org and build the whole thing yourself. It’s quite easy.

As mentioned in the previous section, the winbindd daemon obtains the information that it needs to communication with your primary domain controller from the standard Samba configuration file (usually /etc/samba/smb.conf, unless you installed Samba elsewhere). The following are the critical entries used by the winbindd daemon, all from the [global] section of the Samba configuration file:

To cause your system to consult the winbindd daemon for password and group authentication, you will also have to modify your system’s name service switch to integrate Windows domain authentication. To do this, modify your /etc/nsswitch.conf file to specify that the system obtains password and group information from the Windows domain controller. Correct entries would be the following:

	passwd: files winbind
	group: files winbind

This tells the name service switch to first check the local password and group files on the client system for authentication information and then check the winbindd daemon. This enables you to create local accounts when necessary, giving these local accounts priority while still using Windows domain authentication for most accounts.

Unless you’re using a Linux distribution such as Red Hat, which provides a graphical tool for configuring system authentication (system-config-auth, shown in Figure 1-1), you’ll need to manually modify the PAM configuration files for services that will authenticate using your Windows domain controller. At a minimum, this is the login configuration file (/etc/pam.d/login), and probably also the PAM configuration file for SSH logins (/etc/pam.d/sshd).

Here’s a sample PAM configuration file that uses Windows authentication to enable logins:

	#%PAM-1.0
	auth		sufficient	/lib/security/pam_winbind.so
	auth		required	/lib/security/pam_securetty.so
	auth		required	/lib/security/pam_stack.so service=system-auth debug
				 use_first_pass
	auth		required	/lib/security/pam_nologin.so
	account		required	/lib/security/pam_stack.so service=system-auth
	password	required	/lib/security/pam_stack.so service=system-auth
	session		required	/lib/security/pam_stack.so service=system-auth
	session		optional	/lib/security/pam_console.so

Figure 1-1. Red Hat’s graphical application for configuring Windows authentication

Note that this PAM configuration file accepts Windows authentication as being sufficient to enable a login, but then falls through to the standard Linux authentication sequence if this fails. This enables you to use a mixture of central authentication (through the Windows domain controller) and local authentication (using the traditional Linux/Unix password and group files).

One of the last steps in integrating Linux systems with Windows authentication is to make sure the winbindd daemon starts automatically whenever you boot your system. To do this, make sure a symbolic link to the /etc/init.d/winbind startup script exists for your system’s default runlevel. To start the winbindd daemon manually (i.e., the first time), you can simply run this script with the start argument, as in:

	# /etc/init.d/winbind start

The final step is to actually join the domain from your Linux system. You can do this using the net command, which is part of the Samba suite and is found in the samba-client package mentioned earlier in this hack:

	$ net join member -U Administrator

You’ll be prompted for the Administrator password for the target domain. You do not have to join as the user Administrator—any user with sufficient privileges to join the domain will do.

You should always test any fundamental change to your system’s core authentication sequence before logging out of your system. The easiest way to do this is to enable a service that requires login authentication and then use this to log in via a network connection to your system while you are still actually logged in on the machine. My favorite service for this is the telnet service, but ssh is just as easy (though you will have to modify the /etc/pam.d/sshd PAM configuration file in order to test ssh authentication via your Windows domain controller).

Both Samba and the pam_winbind.so PAM provide excellent debugging options. To put the winbindd daemon in debug mode, log in as root using a local account, add the debug keyword to the pam_winbind entry in the PAM service configuration file that you are using for debugging, and restart the winbindd daemon manually with the -d debug-level option, which displays tons of useful information. I prefer to use debug level 5, which shows each byte in every packet exchanged by the winbind daemon and the domain controller that it is talking to. If this doesn’t provide you with enough information to identify and resolve your problem and you suspect Samba misconfiguration, you can increase the logging level in the Samba configuration file (/etc/samba/smb.conf) by adding the log level winbind:NN command and restarting Samba. This enables you to specify the logging level for Samba activities related to winbind authentication. If you are using an older version of Samba or want coarser logging, you can remove the winbind restriction and simply increase the general Samba logging level by using the command log level NN in your Samba configuration file and restarting Samba. A log level of 5 is sufficient for most debugging. (Remember to disable logging when you’ve resolved your authentication problems, as this creates a huge logfile and has a negative impact on Samba performance.)

Another useful command when analyzing or debugging problems with using Windows domain authentication to authenticate Linux users is the wbinfo command. You can use this command to make sure you’re actually talking to the domain controller and to query the domain controller for various types of information. The following output example shows both the options available to the wbinfo command and a sample command that retrieves the names of known users from the domain controller:

	$ wbinfo
	Usage: wbinfo -ug | -n name | -sSY sid | -UG uid/gid | -tm | -[aA]
	user%password
	Version: 2.2.7-security-rollup-fix
		-u				lists all domain users
		-g				lists all domain groups
		-n name				converts name to sid
		-s sid				converts sid to name
		-N name				converts NetBIOS name to IP (WINS)
		-I IP				converts IP address to NetBIOS name (WINS)
		-U uid				converts uid to sid
		-G gid				converts gid to sid
		-S sid				converts sid to uid
		-Y sid				converts sid to gid
		-t				check shared secret
		-m				list trusted domains
		-r user				get user groups
		-a user%password	authenticate user
		-A user%password	store user and password used by winbindd (root only)
		-p				'ping' winbindd to see if it is alive
		--sequence			show sequence numbers of all domains
		--set-auth-user DOMAINuser%password set password for restrict
	anonymous
	$ wbinfo -u
	_Template
	Administrator
	bill.vonhagen
	build
	[additional output deleted]

Using LDAP in your environment requires that you have a few basic packages installed on your systems, or that you build and install the OpenLDAP software from scratch. If you need to build it yourself, you can download the latest version of the full OpenLDAP package from http://www.openldap.org/software/download. If your Linux systems use a package management system, you’ll need to install:

These packages will give you basic LDAP functionality. However, to integrate them with user lookups and authentication on your client systems, you’ll also need the following:

If you’re building these yourself, their source code is available from PADL Software Pty Ltd, the folks who wrote them, at the URL http://www.padl.com/Contents/OpenSourceSoftware.html.

Finally, you’ll need some useful utilities for migrating existing password, shadow, and group information into your OpenLDAP directory. These are also available from PADL Software Pty Ltd, at the URL http://www.padl.com/download/MigrationTools.tgz.

Many Linux distributions provide graphical utilities for configuring LDAP and LDAP authentication, such as Red Hat’s authconfig application and the LDAP client configuration applet in SUSE’s YaST tool. This hack explains how to do everything from the command line, in case you don’t have access to such utilities. If you’re using either of these systems, the graphical utilities simplify the installation and configuration processes, but it’s always nice to know what’s really required under the covers. You will still have to migrate your user, password, and group data into your LDAP server manually, in any case.

The configuration files for OpenLDAP clients and servers, which are traditionally located in the directory /etc/openldap, are:

Configuring an OpenLDAP server is a fairly simple process. First, you change the suffix entry so that it correctly identifies your domain. For example, the default entry in /etc/openldap/slapd.conf is usually:

	suffix		"dc=my-domain,dc=com"

Change this to reflect your domain. For example, to set up an OpenLDAP server for the domain vonhagen.org, change this line to the following:

	suffix		"dc=vonhagen,dc=org"

Next, change the rootdn entry to reflect the name of a privileged user who has unrestricted access to your OpenLDAP directory. For example, the default entry in /etc/openldap/slapd.conf is usually:

	rootdn		"cn=Manager,dc=my-domain,dc=com"

Continuing with the previous example, you would change this to something like the following for the vonhagen.org domain:

	rootdn		"cn=ldapadmin,dc=vonhagen,dc=org"

Though this user is the equivalent of the root user as far as OpenLDAP is concerned, the name does not have to be that of a real user on your system.

Finally, though optional in some sense, you may want to set a unique password for your OpenLDAP server by modifying the rootpw entry in your /etc/openldap/slapd.conf configuration file. This enables you to configure, test, and correct your OpenLDAP system over your local network, if necessary. For example, the default entry in /etc/openldap/slapd.conf uses the clear-text password secret, as shown here:

	rootpw		secret

You can provide a clear-text or encrypted password as the value for this entry. You can use the slappasswd command to generate an encrypted password that you can paste into the /etc/openldap/slapd.conf file, as in the following example:

	# slappasswd
	New password:
	Re-enter new password:
	{SSHA}x0uopfqDBaylPdv3zfjLqOSkrAUh5GgY

The slappasswd command prompts you for a new password, asks for confirmation, and then displays the encrypted password string preceded by the encryption mechanism used in the password. You then simply replace the value of the existing rootpw option with the generated string, as in the following example:

	rootpw		{SSHA}x0uopfqDBaylPdv3zfjLqOSkrAUh5GgY

You should enable the rootpw option only when initially configuring your OpenLDAP server, and it is necessary to do so only if you must configure your OpenLDAP server over a network. It’s always a good idea to set a unique, encrypted password for your OpenLDAP server that differs from your standard root password, even though the /etc/openldap/slapd.conf file should not be readable by nonprivileged users on your system. Once you have completed your configuration, you should disable this entry by commenting it out. To do so, put a hash mark (#) at the beginning of the line containing the rootpw entry.

Once you have modified your /etc/openldap/slapd.conf file and saved your changes, you can start the OpenLDAP server using the /etc/init.d/ldap script, as in the following example:

	# /etc/init.d/ldap start

As with all startup scripts on Linux systems, you should symlink this file to start up and kill files in the directories associated with your system’s default runlevel to ensure that it starts automatically when you reboot your system.

To configure your LDAP server to provide authentication information, you must first migrate your existing authentication information to the LDAP server. You do this by preparing LDAP Data Interchange Format (LDIF) files that hold the contents of your /etc/passwd,/etc/shadow, and /etc/group files, and then importing those files into the LDAP server.

Creating LDIF files from your existing /etc/passwd, /etc/shadow, and /etc/group files is most easily done by using the migrate_passwd.pl and migrate_group.pl scripts found in the migration tools available at http://www.padl.com/download/MigrationTools.tgz. If you’ve installed OpenLDAP from packages, these scripts may be located on your system in the directory /usr/share/openldap/migration.

To migrate user, password, and group information into your LDAP server so you can use it as a basis for client system authentication, do the following:

After following these steps, you are ready to update your client systems to use LDAP authentication (and test them, of course).

On each system that you want to use the new LDAP authentication server, you must do the following:

The next time you log in on your client system, it will contact your LDAP server for authentication information. When creating new user and group accounts, you will need to use a command-line interface to OpenLDAP (http://quark.humbug.org.au/publications/scripts/ldap/cli/) to create the necessary account information. There are also a number of graphical tools for creating and managing LDAP accounts, but I’m more comfortable with the command line.

Congratulations! You’re now making the most of your network and will rarely, if ever, have to manage local password and group information on individual systems again. Combining this hack with other hacks (such as “Centralize Resources Using NFS” [Hack #56] and “Automount NFS Home Directories with autofs” [Hack #57] ) further liberates individual systems from user-specific data.

Using Kerberos requires that you have a few basic packages installed on your systems, or that you build and install it yourself from scratch. If you need to build it yourself, you can download the latest version from MIT at http://web.mit.edu/kerberos/www/. If your Linux systems use a package management system and you want to use a vanilla Kerberos, you’ll need to install:

After building and installing Kerberos or installing the krb5-workstation, krb5-server, and krb5-libs packages on your the host that will serve as your master KDC, the first step in configuring your Kerberos environment is to set up your master KDC. The process for doing this is the following:

At this point, you’re ready to install and start a Kerberos client. However, before doing anything else, you should verify that your server can hand out tickets by using the kinit command to explicitly request one for the administrative principal that you created earlier. You can then use the klist command to verify its contents, and then destroy the ticket (just to clean up) using the kdestroy command. The following example shows this sequence:

	$ kinit wvh
	Password for [email protected]:
	$ klist
	Ticket cache: FILE:/tmp/krb5cc_0
	Default principal: [email protected]
	Valid starting		Expires		Service principal
	05/03/05 22:09:04 05/04/05 22:09:04 krbtgt/VONHAGEN.ORG/VONHAGEN.ORG
	Kerberos 4 ticket cache: /tmp/tkt0
	klist: You have no tickets cached
	$ kdestroy

Many Linux distributions provide graphical utilities for configuring Kerberos clients, such as Red Hat’s authconfig application and the Kerberos client configuration applets in SUSE’s YaST tool. This hack explains how to do everything from the command line, in case you don’t have access to such utilities. If you’re using either of these systems, the graphical utilities simplify the installation and configuration processes, but it’s always nice to know what’s really required under the covers. You will still have to migrate your user, password, and group data into your Kerberos server manually, in any case.

To install and test the Kerberos client software, do the following:

Congratulations—Kerberos is working! The next step in this hack is to integrate Kerberos into your system’s login authentication process.

To enable Kerberos authentication on a client system, do the following:

That’s all you should have to do. Before logging out of the client, telnet or SSH to it and attempt to log in. If you have any problems with Kerberos login authentication, you can enable PAM debugging in your /etc/krb5.conf file so that you can quickly identify and resolve authentication-related problems with login and other system applications that use PAMs. To do this, simply set the debug entry to true in the PAM section of the [appdefaults] stanza and restart your Kerberos server.

Unfortunately, there is no automated mechanism for migrating existing user and password information to a Kerberos database. You will have to manually add principals for all of your groups and users to the Kerberos database on your KDC, and assign them default passwords. Users can subsequently change their passwords using the kpasswd command found in /usr/kerberos/bin.

Most Linux distributions provide packages that include NIS client and server software, but if yours doesn’t, or you simply want to install the latest and greatest, you’ll need to build and install the following packages from ftp://ftp.kernel.org/pub/linux/utils/net/NIS:

The names of these packages will also include version numbers and an extension based on the archive format that you download (gzip or bzip2).

As mentioned earlier, NIS is the most commonly used distributed authentication mechanism today, largely because it is shipped free with almost all Unix and Unix-like systems. Another reason for the prevalence of NIS is that it’s incredibly easy to set up. This section walks you through the process of setting up an NIS server. Setting up an NIS client is explained in the next section.

To set up an NIS server, log in as or su to root on the system you will be configuring as an NIS server, and do the following:

That’s all there is to it! Your new NIS server is up and running. You can now test that it is working correctly by following the instructions in the next section.

A good sysadmin Zen quote is “If a server is running and it has no clients, is it really working?” This section explains how to set up an NIS client of the server set up in the previous section, after doing some initial configuration so that you can verify that the server is actually doing “the right thing.”

To do some preconfiguration to verify that NIS is actually working, log in as or su to root and edit the /etc/nsswitch.conf file on the system you are using as an NIS client. Find the line that tells your system how to locate password entries and modify that line to look like the following:

	passwd:		files nis [NOTFOUND=return]

This tells your system to look for password information in the local password file and then consult NIS. If the password is not found in either of these locations, the [NOTFOUND=return] command tells your system to give up rather than pursuing any of the other authentication sources that may appear in this nsswitch.conf entry.

Next, save a copy of your system’s /etc/passwd file and then remove all user entries from the existing password file. Leave the root and system service accounts in the file—typically, it’s safe to remove accounts with UIDs greater than 200. As the last line of the newly abbreviated password file, add the following:

	+::::::

This tells NIS to append the contents of the password map (file) retrieved from the NIS server whenever password information is requested.

Notice that the entries for any individual accounts (including your own) have been removed from the abbreviated password file. This enables you to do a fairly simple test to determine whether NIS is working: if you can log in using an account that is not present in the password file on your client system but is present in the password file on your NIS server system, NIS is working correctly.

To set up an NIS client, log in as or su to root on the system you are using as an NIS client and do the following:

You should be able to log in successfully. Congratulations—you’re running NIS! Remember to add setting the domain name and starting the NIS server and client to the startup procedures for each of your NIS client systems.

	#!/usr/bin/perl
	use Net::LDAP;

	## CONFIG
	my $server = "ldap-server";
	my $base = "dc=example,dc=com";
	my $bind = "uid=ldap2nis,ou=People,dc=example,dc=com";
	my $bindpw = 'password';
	my $groupf = "group";
	my $passwf = "passwd";
	my $buildyp = "false";
	## CONNECT
	my $ldap = Net::LDAP->new($server, onerror => 'die' );
	$ldaps = $ldap->start_tls(verify=>'none') or die "Couldn't start tls: $@
";
	$ldap->bind( dn => $bind, password => $bindpw) or die "Bind failed: $@
";

	## PRINT PASSWORD FILE[]

	my $res = $ldap->search(
				base => $base,
				scope => 'sub', # entire tree
				timelimit => 600,
				filter => '(&(objectClass=posixAccount))',
				attrs => ['uid', 'uidNumber', 'gidNumber', 'gecos',
	'homeDirectory', 'loginShell', 'userPassword'],
	);

	open(PASSWORD, ">$passwf");
	while (my $entry = $res->shift_entry) {
		  (my $uid = $entry->get_value('uid')) =~ s/:/./g;
		  (my $uidnum = $entry->get_value('uidNumber')) =~ s/:/./g;
		  (my $gidnum = $entry->get_value('gidNumber')) =~ s/:/./g;
		  (my $gecos = $entry->get_value('gecos')) =~ s/:/./g;
		  (my $homedir = $entry->get_value('homeDirectory')) =~ s/:/./g;
		  (my $shell = $entry->get_value('loginShell')) =~ s/:/./g;
		  (my $up = $entry->get_value('userPassword')) =~ s/:/./g;
		  if (index($up, "{crypt}") != -1) {
			  $up = substr($up, 7);
		  }else{
		  	  $up = crypt($up, "bR"); 
		  } 
		  $passrecord = join(':',$uid,$up,$uidnum,$gidnum,$gecos,$homedir,$shell); 
		  print PASSWORD "$passrecord
";
	}
	close(PASSWORD);
	chmod(0600, $passwf);

	## PRINT GROUP FILE
	my $res = $ldap->search(
		base => $base,
		scope => 'sub', # entire tree
		timelimit => 600,
		filter => '(&(objectClass=posixGroup))',
		attrs => ['cn', 'gidNumber', 'memberuid'],
		
	);

	open(GROUP, ">$groupf");
	while (my $entry = $res->shift_entry) {
	(my $grname = $entry->get_value('cn')) =~ s/:/./g;
	my $grpass = "*";
	(my $grnum = $entry->get_value('gidNumber')) =~ s/:/./g;
	(@members = $entry->get_value('memberuid')) =~ s/:/./g;
	
	if($#members >= 0) {
		$memusers = join(',',@members);
	}else{
		$memusers = "";
	}
	
	$grprecord = join(':', $grname,$grpass,$grnum,$memusers);
	print GROUP "$grprecord
";
  }
  close(GROUP);
  chmod(0600, $groupf);

Assuming you’re storing encrypted password strings in your NIS passwd map, this script, which I call dap2nis, should be configured using the variables near the top to bind as an account that has read access to the userPassword attribute for the user entries. Otherwise, you’ll get nothing back for that attribute, and your resulting NIS maps won’t be useful as authentication sources when they’re pushed out.

You can test the code by first making a test directory and making the script executable. Next, be sure to configure it to talk to your LDAP server using the config variables near the top of the script. Once that’s all done, running the program should produce passwd and group files in the test directory. These should be valid NIS maps, ready to be pushed out. However, before taking that step, you should run a diff against the current NIS maps to check for any anomalies that reflect errors in the map generation rather than simple changes that have occurred in LDAP but are not yet reflected in NIS. Here are a few commands from a hypothetical test session:

	# ./dap2nis
	# ypcat passwd > yppass.out
	# ypcat group > ypgrp.out
	# diff yppass.out passwd
	# diff ypgrp.out group

The only output you should see from the diff commands should be valid changes that have not yet been propagated to NIS. Once you’ve tested thoroughly, you can put the script in root’s crontab file, with an entry like this:

	*/7 * * * * /var/adm/bin/dap2nis

This entry says to run the script every seven minutes, all the time, every day.

The only thing the dap2nis script does not do in its current incarnation is actually perform a cd var/yp/; make, which would normally push out the NIS maps. Depending on your environment, you may not want this in this particular script. Instead, you might put in another cron job that pushes out NIS maps every four minutes, which would allow for changes to be pushed out automatically to reflect changes that were made to maps not covered by this script. Creating a separate cron job to push out the NIS maps also ensures that if this script is ever retired or pulled out of production, your maps will still get pushed out in an automated fashion.