Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Configuring PAM and Identity Synchronization for Windows

Note –

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

Use the following steps to configure Identity Synchronization for Windows and PAM for environments in which passwords can change on Windows:

  1. Configure an LDAP repository for PAM (Step 1: Configure an LDAP Repository for PAM)

  2. Install and configure Identity Synchronization for Windows to synchronize the LDAP repository and Windows (Step 2: Configuring Identity Synchronization for Windows

  3. Populate the LDAP repository with user data (Step 3: Populating the LDAP Repository)

  4. Configure a Solaris host to use the LDAP repository (Step 4: Configuring a Solaris Host to Use PAM)

  5. Establish password authentication through the LDAP repository and enable users to change their own passwords (Step 5: Verifying that PAM is Interoperating with the LDAP Store)

  6. Verify that user information (including passwords) flows between environments (Step 6: Demonstrating that User Changes are Flowing to the Reciprocal Environment)

    The rest of this section provides detailed information about each step and uses examples to illustrate the process.

Step 1: Configure an LDAP Repository for PAM

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

Note –

Before you begin, consult the Sun Java System Directory Server Enterprise Edition 6.1 Installation Guide to verify that you are using a supported directory server.

To get PAM to work with Directory Server, edit the /usr/lib/ldap/idsconfig script and change 5 to 6 in the following code:

if [ "${IDS_MAJVER}" != "5" ]; then

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

  1. Configure the LDAP store using the Solaris 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
    Note –

    While executing the idsconfig command line tool, you need to know the values that have to be provided to the various configuration parameters. If you do not know the values, provide the default values that are prompted (other than the configuration parameters 1,2 and 4).

  2. Change the value of the configuration parameters by selecting the configuration number against them.

  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 scenario. If you are working in a test environment where you can change DNS entries and set machine IP addresses to arbitrary values, you could use the names and addresses provided in this appendix.

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

  6. After idsconfig stores the generated configuration, the idsconfig tool will direct you to create virtual list view (VLV) indexes.

    Note –

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

    Managing Browsing Indexes in Sun Java System Directory Server Enterprise Edition 6.1 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 seen from the Sun Java System Directory Server console:

    Resulting Topology

    When you are finished configuring the LDAP repository for PAM, continue to Step 3: Populating the LDAP Repository.

Step 2: Configuring Identity Synchronization for Windows

Now you can begin the process of bridging the LDAP store with the Windows’ authentication system. You accomplish this process by installing and configuring Identity Synchronization for Windows against the following two systems:

Note –

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

When you finish configuring Identity Synchronization for Windows, continue to Step 3: Populating the LDAP Repository.

Step 3: Populating the LDAP Repository

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

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


In addition, you want to use an ou=people “container” that is subordinate to the Base DN you provided to idsconfig. You may have to make contextual changes to the Base DN you are going to use.

Use the following steps to populate the LDAP repository:

  1. In the Directory Server Control Center console, select the Entry Management tab and then select the Browse tab, the various entity management controls display in the right pane.

  2. Press New Entry to display the New Entry page.

  3. Enter 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 selecting an option from the Entry type drop-down menu and then press Next. Based on the object class you associate with your entity, number of different parameters display

    Choosing Object Class
  5. Enter the appropriate values and press Next. The summarized information of the entity displays.

    Configuring Attributes
  6. Click Finish to save the changes.

    Displaying Summary Information
  7. Verify that the new user (George Washington) is displayed in the console.

    Java System Directory Service Control Center

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

Step 4: Configuring a Solaris Host 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.

To configure a Solaris host and create a PAM client you must

  1. Install and configure a test Solaris system.

  2. Configure the client machine.

  3. Specify new rules for authentication and password management.

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

Installing and Configuring a Solaris Test System

Install and configure a test Solaris system as an independent, standalone machine.

Note –

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

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

Configuring the Client Machine

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

You must configure a PAM client machine 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 ldapclient command, which stores the client’s configuration information on the local host.

Note –

Be sure to make a back-up 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 image illustrates an example ldapclient command:

Figure A–1 Example ldapclient Command

Example ldapclient Command

Specifying Rules for Authentication and Password Management

Note –

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

When you configure a Solaris host to use PAM, change the /etc/pam.conf file to incorporate the new rules you want it to use for authentication and password management. (See Introducing Windows NT into the configuration for an example /etc/pam.conf file.)

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

To recover from this situation:

  1. Edit the pam.conf file in the current terminal/command session.

  2. In a new terminal window, try connecting to the localhost 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 terminal/command window from .

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

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

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

    The changes you must make to /etc/pam.conf are trivial, but important. They are explained here:


For purposes of authentication, you must edit the 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 figure 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, the line’s order is important here.)

    The new rule requires the service to include PAM_LDAP when deciding 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 local user log on. A local user is a user who is permitted by /etc/nsswitch.conf directives to examine files (such as the root account) and is enumerated 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, you could make an equally powerful case 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, it is important to configure PAM in such a way so that it does not access the LDAP back-end store if the user information has been saved in the local files. You can address this situation 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, then the system will provide an appropriate error message.

When you have finished configuring the Solaris host, continue to Step 5: Verifying that PAM is Interoperating with the LDAP Store.

Step 5: Verifying that PAM is Interoperating with the LDAP Store

You are now ready to test whether the newly configured Solaris host can operate as a PAM client. However, before trying to log in as the example user, George Washington, you need to “cheat” just a bit.

Note that George’s default home directory is /pres/home/gwashington. This directory does not yet exist on your test host nor have you configured the auto_home system on which to mount that file system automatically. You can create the directory manually to avoid any kind of problem.

Figure A–2 Creating a Directory

Creating a Directory

You should be able to see the PAM system in action immediately (because gwashing is both understood and displayed). The following image shows that the PAM LDAP client system you configured can authenticate as gwashing. In addition, this figure demonstrates that a password change can be accomplished and that the new password will be accepted on a subsequent authentication request.

Figure A–3 Configured PAM LDAP System

Configured PAM LDAP System

If you check the LDAP store log (specifically looking for non-search operations) you should see an audit of the LDAP operations done in support of the preceding log-in and password-change test.

Figure A–4 Auditing LDAP Operations

Auditing LDAP Operations

Step 6: Demonstrating that User Changes are Flowing 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:

Case 1

Case 1 is trivial — there is no work to do on either system because the entries are current.

Case 2

In Case 2, the LDAP store is in a state of waiting. Specifically, the system is waiting for an opportunity to capture the current, correct password for the LDAP store. In this case, a properly configured Identity Synchronization for Windows system marks the corresponding entry in the LDAP store as outdated or stale.

When an Identity Synchronization for Windows - enhanced Directory Server system gets a bind against a stale user, Identity Synchronization for Windows replays the given bind credentials to the configured Windows Active Directory to see if the user-supplied password is acceptable. If Active Directory authenticates the password, Identity Synchronization for Windows modifies the LDAP store so that it now possesses the password. Directory Server may eventually hash the value as part of its password policy and clears the stale status.

This process is known as on-demand synchronization, which results in both systems becoming synchronized with regard to the given entry after a successful bind occurs against the LDAP store.

Case 3

Case 3 can occur under normal circumstances, but most frequently occurs due to one of the following situations:

Case 4

This case is a contradiction. If both systems are stale, then how can you ascertain which system contains the authoritative information? Human intervention will be required in this case, and you must decide where to place the true state of an entry into one of the three, previously mentioned cases.

Note –

This situation can lead you into a very tedious process as you may be required to examine every user entry

For example, moving the entry from your LDAP store creates Case 3. If you created an new user called George Washington on a Solaris PAM machine, 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 in the following section.

ProcedureVerifying the 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 right) and select Users.

    Verifying entities
  3. Right-click the George Washington entry and select Properties from the pop-up menu.

    When the George Washington Properties dialog box is displayed, check the Account options section and you can see that the User must change password at next logon check box is enabled, which means George Washington will be required to change his password the next time he logs on.

    Displaying properties for the selected entity
  4. If you log in as George Washington, you can see that 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. Enter and confirm a new password, but do not provide a value for the Old Password field.

    This is first time the user has logged on (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, George Washington's entry has moved from Case 3 (where the Windows entry is stale and the LDAP store is current) to Case 2 (where Windows is current and the LDAP store entry is stale).

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