To Configure a Solaris System to Use PAM

After configuring the LDAP store, you must configure a Solaris system and create a PAM client to test the viability of PAM-based authentication as follows.

1. Install and configure a test Solaris system.

2. Configure the PAM client.

3. Specify new rules for authentication and password management.

To illustrate this process, example instructions and guidelines are provided in the next three sections.

Installing and Configuring a Solaris Test System

Install and configure a test Solaris system on an independent, stand-alone machine.

To simplify this example, consider configuring a system that is devoid of any naming service directives (such as NIS or NIS+).

Consider using a Solaris 9 4/04 x86 based system, which contains patches required for PAM and its associated subsystems.

Configuring the PAM Client

The following example instructions assume that you have installed and configured the Solaris test system as described in the previous section.

You must configure a PAM client to locate the LDAP host with a repository that the client will use to access (and effectively change) the LDAP store. To configure the PAM client, use the Solaris OS ldapclient command, which stores the client’s configuration information on the local host.

Make a backup copy of the /etc/nsswitch.conf file before you run the ldapclient command. Running ldapclient has several side effects, which includes completely replacing the system’s /etc/nsswitch.conf file with a copy of the content in /etc/nsswitch.ldap.

The following screen illustrates an example ldapclient command:

Other guidelines include the following:

• Use an IP address for this configuration instead of a DNS name, because DNS might not available when the PAM client needs it.

• Use a proxy credential set to prevent anonymous authenticators from manipulating data in the LDAP store.

  The system provides a set of proxy credentials that you can use when manipulating PAM data on the host LDAP store. These proxy credentials match those created when you used the idsconfig command to initialize the LDAP store.

  The generated configuration stores the proxy’s password as an encrypted value, which is done for security purposes.

In addition to generating the requisite LDAP contact information, running ldapclient replaces the contents of the /etc/nsswitch.conf file (the file you backed up earlier) with a copy of the contents in /etc/nsswitch.ldap. Consequently, most (or all) of the directives found in /etc/nsswitch.conf will include the LDAP directive, which means that the LDAP store will be consulted when resolving the associated service request.

In this example, the resulting /etc/nsswitch.conf file left on the system by the ldapclient command dropped the DNS directive from the list of used services when resolving hosts. As the example LDAP store might not be populated with the requisite host information needed to supplant DNS, the /etc/nsswitch.conf file is adjusted. In this example, this is the only change made to the post ldapclient command version of the /etc/nsswitch.conf file.

Edit the host’s declaration to read as follows:

hosts: files ldap dns

Do not use the following reconfigured value (using ldapclient):

hosts: ldap [NOTFOUND=return] files

This adjustment might not address your environment’s needs correctly if you are running your DNS from the LDAP store. Only apply this change if your environment’s context depends on it. In addition, continue to compare and contrast the service directives with the effective /etc/nsswitch.conf file to the pre-ldapclient variant to validate that all services are now being directed correctly.

Specifying Rules for Authentication and Password Management

The example instructions provided in this section assume that you completed the tasks as described in Installing and Configuring a Solaris Test System.

When you configure a Solaris system to use PAM, change the /etc/pam.conf file to incorporate the new rules that you want it to use for authentication and password management. For an example, see Example /etc/pam.conf File.

Before making any changes to the /etc/pam.conf file, make sure that you make a backup copy of the original /etc/pam.conf file. Changes made to the /etc/nsswitch.conf and /etc/pam.conf files can render your PAM client inaccessible, which means that your configuration will deny everyone’s (including root) authentication access to the machine.

If you need to recover from a situation of this type, do the following:

1. Edit the pam.conf file in the current session. See Authentication and Password Management.

2. In a new terminal window, try connecting to the local host using the rsh or ssh command and then try logging in.

   • If you fail to authenticate, you can still correct the problem using the open window that you used in the previous step.

   • If you are still unable to recover, restore the /etc/nsswitch.conf and /etc/pam.conf files to their original state.

     Using the Solaris OS sys-unconfig command might not restore your system because this command does not affect the /etc/nsswitch.conf and /etc/pam.conf files.

3. Repeat steps 1 and 2 until you achieve the expected system behavior.

The changes you must make to /etc/pam.conf are minor, but important, and are explained in the next two sections:

Authentication

For purposes of authentication, you must edit the /etc/pam.conf file as follows:

1. Locate any entries in the original /etc/pam.conf file that direct the system to use a rule requiring PAM_UNIX_AUTH, and edit them to accept a binding directive and to pass the server_policy parameter to the PAM_UNIX_AUTH module.

   The following output shows a diff between the original /etc/pam.conf file and the edited file.

   

2. Edit the file to add a new rule after the altered rule line. The /etc/pam.conf file is processed from the top down so line order is important.

   The new rule requires the service to include PAM_LDAP when determining whether to accept an authentication request. The use_first_pass parameter tells the PAM_LDAP module that it must accept a password collected by an earlier rule’s module (usually satisfied by the PAM_AUTHTOK_GET module).

   ---

   Note –

   A use case that deserves special consideration is how PAM treats the login of a local user. A local user is a user who is permitted by /etc/nsswitch.conf directives to examine files (such as the root account) and is listed in the /etc/passwd file. Local users are not necessarily stored in the LDAP store.

   Allowing the root user to be listed in the LDAP store would simplify management of an important user account that spans the topology. However, an equally powerful case could be made for systems whose root user must be kept “private” for a given machine.

   To accommodate the need to keep an account (such as root) as a local user, PAM must be configured so it does not access the LDAP back-end store if the user information has been saved in the local files. This situation can be addressed by specifying the server_policy parameter for the PAM_UNIX_AUTH module in the /etc/pam.conf configuration file.

   ---

Password Management

The only effective change required for password management is to append the server_policy parameter to the PAM_AUTHTOK_STORE module. When you use the server_policy parameter, the module will update passwords for local users (if found) or access the LDAP store accordingly. If the module cannot find a user either locally or in the LDAP store, the system will provide an appropriate error message.

When you have finished configuring the Solaris test machine, continue to To Verify That PAM Is Interoperating With the LDAP Store.