test

Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Appendix A Pluggable Authentication Modules

This appendix explains how to configure Sun Java System Identity Synchronization for Windows 6.0 and pluggable authentication modules (PAM) so that an LDAP store can provide synchronization capabilities between Solaris and Windows systems.

This appendix covers the following topics:

Note –

In this appendix, Windows refers to Windows systems using Active Directory for authentication. Windows NT systems may impose different approaches.

Advantages of Combining PAM and Identity Synchronization for Windows

If your enterprise contains both Solaris and Windows systems, you can simplify the administration of the user community if you use Identity Synchronization for Windows to manage the two sets of users as a single set.

Combining PAM and Identity Synchronization for Windows can accomplish the following goals:

Note –

The Solaris OS implementation of PAM has long-offered the ability to use an LDAP store. However, starting with the Solaris 9 OS, PAM modules are included by default, which makes it possible to use a product such as Identity Synchronization for Windows.

You can update the Solaris 8 OS to support this functionality by using Patch Number 108993 for SPARC® based systems or Patch Number 108994 for x86 based systems.

While some Solaris software PAM modules are LDAP-aware, other modules do not use LDAP in a way that triggers Identity Synchronization for Windows interception actions.

For example, when you configure the PAM_UNIX module to use LDAP (using a directive specified in the /etc/nsswitch.conf file), the module never binds (as the user in question) to the LDAP store when authenticating. Instead, the PAM_UNIX module reads the user's LDAP entry, internally compares the password found on the LDAP entry to the password provided, and makes its authentication decision accordingly.

Because the PAM_UNIX module authentication is done outside the purview of the LDAP store, so none of the hooks put into place by Identity Synchronization for Windows will be used. Consequently, passwords will fail to replicate from the LDAP store to Windows.

To initiate the synchronization process discussed in this appendix, Identity Synchronization for Windows requires that all authentication systems bind to the LDAP store. Furthermore, the binding mechanism must present the user's password in a clear manner, such as a simple bind, which rules out the use of the Simple Authentication and Security Layer (SASL) and Digest mechanisms. Using Transport Layer Security (TLS) for the connection between PAM and the LDAP store makes the use of simple binds acceptable for security.

The PAM_UNIX module’s authentication methods should suffice in environments where passwords never change or where password changes always flow from the LDAP store to Windows. However, you must not use the PAM_UNIX module in environments where passwords change on Windows.

In contrast to the PAM_UNIX module, the PAM_LDAP module binds to the LDAP store using a preformed, “user-centric” distinguished name (DN) and a user-provided password when authenticating. This binding action allows Identity Synchronization for Windows to maintain the synchronization of an entry. Thus, you will use the PAM_LDAP module in conjunction with Identity Synchronization for Windows and existing PAM modules.

The following section explains how to configure PAM and Identity Synchronization for Windows.

Configuring PAM and Identity Synchronization for Windows

Note –

In this section, Windows refers to Windows systems using Active Directory for authentication. Windows NT systems might require different approaches.

To configure Identity Synchronization for Windows and PAM for environments in which passwords can change on Windows, involves completing the following tasks:

  1. To Configure an LDAP Repository for PAM

  2. To Install and Configuring Identity Synchronization for Windows

  3. To Populate the LDAP Repository

  4. To Configure a Solaris System to Use PAM

  5. To Verify That PAM Is Interoperating With the LDAP Store

  6. To Demonstrate That User Changes Flow to the Reciprocal Environment

    The remainder of this section provides procedures for each task and includes examples to illustrate the configuration process.

To Configure an LDAP Repository for PAM

This procedure describes how to configure an Identity Synchronization for Windows-supported LDAP repository for PAM, using the following example information:

Prerequisites to configure an Identity Synchronization for Windows- supported LDAP repository for PAM.

Use the following steps to configure an Identity Synchronization for Windows- supported LDAP repository for PAM.

  1. Configure the LDAP store by using the Solaris OS idsconfig command-line tool.

    The idsconfig tool prompts you for values that are needed to form the directory information tree (DIT) to be contained in the LDAP store. The idsconfig tool will manipulate the requisite LDAP store schema to accommodate the impending user population.

    When you configure the test system, the following idsconfig summary screen is displayed:

    Summary of Configuration Screen

  2. To change the value of a configuration parameter, type its associated configuration number.

  3. Select an option from the list of predefined options that can be supplied to the selected parameter.

  4. Evaluate the following key parameters’ values:

    • Domain to serve

    • Base DN to setup

    • Profile name to create

    • Service Auth Method pam_ldap

    If necessary, use the idsconfig tool to change the context of these parameter values so they are appropriate for your deployment. If you are working in a test environment where you can change DNS entries and set machine IP addresses to arbitrary values, you may use the names and addresses provided in this appendix.

  5. Continue with the proxy creation initiated by the idsconfig tool by providing the appropriate values (default or custom) for the various parameters.

  6. After the configuration is complete and idsconfig stores the generated configuration, create virtual list view (VLV) indexes when prompted.

    Note –

    VLV indexes (also called browsing indexes) enable PAM to quickly search for groups, users, and so forth. For information about creating VLV indexes, go to:

    Managing Browsing Indexes in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide

    Pay particular attention to the number of VLV indexes that you are prompted to create. The idsconfig tool will provide a list of VLV indexes that are contextually sensitive to the state in which it finds the LDAP store.

    The following figure shows the resulting topology, as displayed on the Sun Java System Directory Server Console.

    Resulting Topology

    When you are finished configuring the LDAP repository for PAM, continue to To Populate the LDAP Repository.

To Install and Configuring Identity Synchronization for Windows

This procedure starts the process of bridging the LDAP store with the Windows authentication system. Install and configure Identity Synchronization for Windows on the following two systems:

You can install Identity Synchronization for Windows on the Solaris host (LDAPHOST.EXAMPLE.COM) and then configure the software so that all of the distributed processes required by Identity Synchronization for Windows will run on LDAPHOST.EXAMPLE.COM.

Instructions for installing and configuring Identity Synchronization for Windows are provided in the Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide.

When you finish configuring Identity Synchronization for Windows, continue to To Populate the LDAP Repository.

To Populate the LDAP Repository

After configuring an LDAP repository for PAM, you push user entries to the LDAP store.

For example, you create a new, single user named George Washington that is subordinate to the following entry:

ou=people,dc=pam,dc=example,dc=com

In addition, you use an ou=people container that is subordinate to the base DN you provided to idsconfig. You might have to make contextual changes to the base DN you are going to use.

  1. In the Directory Service Control Center Console, click the Entry Management tab, and then the Browse tab. The various entity management controls are displayed in the right pane.

  2. Click New Entry to display the New Entry screen.

  3. Type a value in the Entry Parent DN field to specify the location to save the entity in Directory Server and click Next.

    Specifying entry location

  4. Associate your entity with an object class by choosing an option from the Entry Type drop-down menu and press Next.

    Choosing Object Class

    Based on the object class that you associated with your entity, a number of different attributes are displayed.

    Configuring Attributes

  5. Enter the appropriate values for the parameters and press Next.

    A summary of the entity is displayed.

    Displaying Summary Information

  6. Verify that the new user (George Washington) is displayed in the console.

  7. Click Finish.

PAM clients can now authenticate against (and change the password for) this entry.

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.

Note –

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.

Note –

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:

Example ldapclient Command

Other guidelines include the following:

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

Note –

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.

    Edited /etc/pam.conf 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.

To Verify That PAM Is Interoperating With the LDAP Store

You now test whether the newly configured Solaris system can operate as a PAM client.

  1. At the command line, create George default home directory, /pres/home/gwashington, on your test system.

    Creating a Directory

    The PAM client is working because gwashing is both understood and displayed.

  2. Configure the auto_home system on which to mount that file system automatically. The following output shows that the PAM LDAP client system that you configured can authenticate as gwashing. In addition, this output demonstrates that a password can be changed and that the new password will be accepted on a subsequent authentication request.

    Configured PAM LDAP System

  3. Check the LDAP store log for non-search operations. An audit of the LDAP operations completed in support of the preceding login and password-change test is displayed.

    Auditing LDAP Operations

To Demonstrate That User Changes Flow to the Reciprocal Environment

Both Windows and the LDAP store (if so configured) use a one-way hash when storing passwords. This configuration prevents true replication of password data between the two systems, but does not prevent the password synchronization.

For an environment that is participating in bidirectional password synchronization, any existing user’s entry being tracked in both environments must be in one of the following states:

Note –

This situation can lead to a very tedious process as you might have to examine every user entry.

If you created a user called George Washington on a Solaris system that operates as a PAM client, and then use the idsync resync command to push the entry to Windows, you can verify that Identity Synchronization for Windows has also created the entry on Windows as explained in the following procedure.

ProcedureTo Verify Entries on Windows

  1. From the Windows Start menu, go to Control Panel -> Administrative Tools -> Active Directory User and Computers.

  2. When the Active Directory User and Computers window is displayed, go the Active Directory Users pane (on the left) and click Users.

    Verifying entities

  3. Right-click the George Washington entry, and choose Properties.

    When the George Washington Properties dialog box is displayed, look at the Account options section. It shows that the User Must Change Password at Next Logon check box is selected, which means that George Washington will be required to change his password the next time that he logs in.

    Displaying properties for the selected entity

  4. Log in as George Washington.

    Windows is correctly tracking the entry because the log-in attempt displays the Logon Message dialog box stating, “Your password has expired and must be changed.”

  5. Click OK to close the Logon Message dialog box and to display the Change Password dialog box to provide a new password.

  6. Type and confirm a new password, but do not provide a value for the Old Password field.

    This is first time the user has logged in (since being created over protocol), so supplying an old password value will cause an error message and Windows will ask you to enter the new password again.

  7. Click OK to save the new password and close the Change Password dialog box.

    If Windows accepts the new password, a message is displayed stating that the new password has been accepted.

    At this point, the George Washington entry has moved from where the Windows entry is stale and the LDAP store is current to where Windows is current and the LDAP store entry is stale.

    George Washington's entry will maintain this condition until the next time that it binds to the LDAP store. At that time, the entry will move to where the entry is current on both Windows and the LDAP store.

Configuring Systems to Prevent Eavesdropping

This appendix does not include procedure for configuring systems so that communication between systems is always conducted securely to prevent eavesdropping.

Some of the required configuration changes are addressed when you configure Identity Synchronization for Windows. For example, starting with Windows 2000, the password policies require that all password changes be made using secure methods. Consequently, simply configuring the Windows system partially addresses the security requirement.

However, eavesdroppers can still see the bind attempts when Identity Synchronization for Windows components replay bind credentials. To address this issue, you must configure Identity Synchronization for Windows to communicate securely with its Windows data source by configuring the Identity Synchronization for Windows Connectors to trust certificates offered by the Windows Active Directory system.

In addition, you must ensure that all clients authenticating to the LDAP store do so over TLS. You must configure PAM clients to trust the LDAP store and ensure that idsconfig specifies TLS:pam_ldap:simple as the only authentication method for the LDAP store.

The root accounts cannot use the passwd command arbitrarily to change a user’s password on PAM client. You might consider this restriction to be a limitation, depending on whether you trust the PAM client administrators.

Introducing Windows NT Into the Configuration

While the term Windows refers to Windows platforms using Active Directory for authentication, the system being discussed in this appendix can use Windows NT in place of (or along with) newer variations of Windows.

Be aware, however, that Windows NT lacks the ability to use on-demand synchronization normally provided by Identity Synchronization for Windows.

The Identity Synchronization for Windows on-demand synchronization process must be able to bind to Windows over LDAP, with a set of candidate credentials, an ability that the Windows NT authentication system lacks. When Identity Synchronization for Windows is configured with Windows NT, it expects password changes to be captured at their source and at the time the change is made. This capture requirement has ramifications when you initially start a system that uses Identity Synchronization for Windows. Specifically, Identity Synchronization for Windows needs to see a password change for any entry before the entry is actually synchronized.

Synchronization in Windows NT environment involves modifying the passwords of all entries in the LDAP store using an LDAP-based utility. As these modifications go through the LDAP store system, Identity Synchronization for Windows forwards the captured passwords to the Windows NT system, and resulting in no stale passwords on these two systems. However, because you created the passwords by deterministic means, these passwords might be easy to guess.

You can limit potential security breaches if you use Windows NT password policy to force all users to change their password at their next login. As each user changes their password, the Identity Synchronization for Windows password DLL installed on the Primary Domain Controller forwards the password change to the LDAP store.

Example /etc/pam.conf File

The following /etc/pam.conf file is provided to help you configure and run Identity Synchronization for Windows and PAM.

Note –

This /etc/pam.conf file is only an example.

The file’s configuration is not appropriate for all situations. Analyze the content thoroughly before using this file in a production environment.

Example A–1 Example /etc/pam.conf File


#
#ident    "@(#)pam.conf    1.20    02/01/23 SMI"
#
# Copyright 1996-2006 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login    auth requisite    pam_authtok_get.so.1
login    auth required    pam_dhkeys.so.1
login    auth required    pam_dial_auth.so.1
login    auth binding    pam_unix_auth.so.1 server_policy
login    auth required    pam_ldap.so.1 use_first_pass
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin    auth sufficient    pam_rhosts_auth.so.1
rlogin    auth requisite    pam_authtok_get.so.1
rlogin    auth required    pam_dhkeys.so.1
rlogin    auth binding    pam_unix_auth.so.1 server_policy
rlogin    auth required    pam_ldap.so.1 use_first_pass
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh    auth sufficient    pam_rhosts_auth.so.1
rsh    auth binding    pam_unix_auth.so.1 server_policy
rsh    auth required    pam_ldap.so.1 use_first_pass
#
# PPP service (explicit because of pam_dial_auth)
#
ppp    auth requisite    pam_authtok_get.so.1
ppp    auth required    pam_dhkeys.so.1
ppp    auth required    pam_dial_auth.so.1
ppp    auth binding    pam_unix_auth.so.1 server_policy
ppp    auth required    pam_ldap.so.1 use_first_pass
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authenctication
#
other    auth requisite    pam_authtok_get.so.1
other    auth required    pam_dhkeys.so.1
other    auth binding    pam_unix_auth.so.1 server_policy
other    auth required    pam_ldap.so.1 use_first_pass
#
# passwd command (explicit because of a different authentication module)
#
passwd    auth binding    pam_passwd_auth.so.1 server_policy
passwd    auth required    pam_ldap.so.1 use_first_pass
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron    account required    pam_projects.so.1
cron    account required    pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other    account requisite    pam_roles.so.1
other    account required    pam_projects.so.1
other    account required    pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other    session required    pam_unix_session.so.1
#
# Default definition for  Password management
# Used when service name is not explicitly mentioned for password management
#
other    password required    pam_dhkeys.so.1
other    password requisite    pam_authtok_get.so.1
other    password requisite    pam_authtok_check.so.1
other    password required    pam_authtok_store.so.1 server_policy
#
# Support for Kerberos V5 authentication (uncomment to use Kerberos)
#
#rlogin    auth optional    pam_krb5.so.1 try_first_pass
#login    auth optional    pam_krb5.so.1 try_first_pass
#other    auth optional    pam_krb5.so.1 try_first_pass
#cron    account optional     pam_krb5.so.1
#other    account optional     pam_krb5.so.1
#other    session optional     pam_krb5.so.1
#other    password optional     pam_krb5.so.1 try_first_pass