Password Synchronization for IBM Tivoli Directory Integrator 6.0


Contents

Password Synchronization with IBM Tivoli Directory Integrator 6.0
Building blocks
Building the solution
Available specialized components
Password Synchronizers
Password Stores
Specialized Connectors
Password Synchronization Architecture and Workflow
The Password Store Interface
Architecture options
Security
Reliability
Password Synchronizers
Password Synchronizer for IBM Tivoli Directory Server
Password Synchronizer for Sun ONE Directory Server
Password Synchronizer for Windows
Password Synchronizer for Domino
Password Stores
LDAP Password Store
MQ Everyplace Password Store

Password Synchronization with IBM Tivoli Directory Integrator 6.0

The IBM(R) Tivoli(R) Directory Integrator provides an infrastructure and a number of ready-to-use components for implementing solutions that synchronize user passwords in heterogeneous software environments.

A password synchronization solution built with IBM Tivoli Directory Integrator can intercept password changes on a number of systems. The intercepted changes can be directed back into:

Synchronization is achieved through the IBM Tivoli Directory Integrator AssemblyLines which can be configured to propagate the intercepted passwords to desired systems.

Building blocks

The components that make up a password synchronization solution are:

Password Synchronizers
Components which are deployed on the system where password changes occur. They are responsible for intercepting plain (unencrypted) values of the passwords as they are changed.
Password Stores
Components that receive the intercepted passwords, encrypt and store them in locations that can be accessed by the IBM Tivoli Directory Integrator.
Connectors
These are either standard or specialized IBM Tivoli Directory Integrator Connectors. They connect to locations where the intercepted and encrypted passwords are stored and are able to retrieve and decrypt the passwords.
AssemblyLines
The AssemblyLines use Connectors to get the intercepted passwords and then build custom logic for sending the passwords to other software systems.
EventHandlers (optional)
The use of EventHandlers can further automate or schedule the password synchronization process.

Building the solution

The Password Synchronizers, Password Stores and Connectors are ready-to-use components included in the IBM Tivoli Directory Integrator 6.0. As a result, implementing the solution that intercepts the passwords and makes them accessible from IBM Tivoli Directory Integrator is achieved by deploying and configuring these components.

For the part of the solution that consolidates passwords intercepted from different sources and feeds these passwords into systems that need to be synchronized, a custom AssemblyLine must be implemented. The look of the AssemblyLine depends mostly on the custom environment and the requirements for the particular solution. IBM Tivoli Directory Integrator does not include these AssemblyLines; they are implemented by the customer.

A password synchronization AssemblyLine usually uses Iterator Connectors to retrieve passwords from the Password Stores. The AssemblyLine then uses other standard Connectors to set these passwords into other systems. If the systems that are synchronized have custom requirements for setting user passwords, these requirements must be addressed in the AssemblyLine and the Connectors that set these passwords. Such customization might consist of setting certain Connector parameters, for example, turning on the Auto Map AD Password option in the LDAP Connector to set user passwords in Active Directory. In more complex cases, scripting might be necessary.

A password synchronization solution might include IBM Tivoli Directory Integrator EventHandlers to automate the process of synchronization. For example, an EventHandler might listen for changes in the repository where a Password Store component stores the intercepted passwords and trigger the synchronization AssemblyLine whenever a new password is intercepted. Another example might be using a Timer EventHandler that starts the synchronization AssemblyLine on a schedule.

Represented here are some basic and common steps. Each of the components mentioned previously provides interfaces which facilitate the tuning of behavior. Also, the various components can be combined with each other to create custom solutions. These key features provide flexibility for building solutions that meet custom requirements and limitations. The password synchronization suite is mostly comprised of the specialized components that intercept the passwords and make them accessible for the IBM Tivoli Directory Integrator. Once the IBM Tivoli Directory Integrator can access the intercepted passwords through its Connectors, the whole flexibility and openness of the IBM Tivoli Directory Integrator architecture can be leveraged in organizing the process of password retrieval and propagation to other systems.

Available specialized components

The following specialized password synchronization components are currently available:

Password Synchronizers

Password Synchronizer for Windows(R) NT/2000/XP/2003 Server
Intercepts the Windows login password change.
Password Synchronizer for IBM Tivoli Directory Server
Intercepts IBM Tivoli Directory Server password changes.
Password Synchronizer for Sun ONE Directory Server
Intercepts Sun ONE Directory Server password changes.
Password Synchronizer for Domino(TM)
Intercepts changes of the HTTP password for Lotus(R) Notes(R) users.

Password Stores

LDAP Password Store
Provides the function necessary to store the intercepted user passwords in LDAP directory servers.
MQ Everyplace(R) Password Store
Provides the function necessary to store user passwords into IBM WebSphere(R) MQ Everyplace.

Specialized Connectors

MQe Password Store Connector
Provides the function necessary to retrieve password update messages from IBM WebSphere MQ Everyplace and send them to IBM Tivoli Directory Integrator.

Besides the specialized components for password synchronization, there are other standard IBM Tivoli Directory Integrator components that can fit into a password synchronization solution. For example, if the LDAP Password Store is used to store changes into an LDAP server, the LDAP Connector can subsequently retrieve the intercepted passwords.

Password Synchronization Architecture and Workflow

There are several layers in the IBM Tivoli Directory Integrator Password Synchronizer architecture.

Artwork for architecture

Target System on the diagram designates the software system where we want to intercept password changes. The Password Synchronizer component hooks into the Target System using custom interfaces provided by the Target System. The Password Synchronizer component intercepts password changes as they occur in the Target System and before the password is hashed irreversibly.

Also, a Password Store component is deployed on the Target System. Once the Password Synchronizer intercepts a password change it immediately sends the password to the Password Store. The Password Store encrypts the password and sends it to a Password Storage.

The Password Storage is the second layer in the architecture and represents a persistent storage system (for example, an LDAP directory, or WebSphere MQ Everyplace) where the intercepted and already-encrypted passwords are stored in a form and location that are accessible from the IBM Tivoli Directory Integrator. The Password Storage can reside on the Target System machine or on another network machine.

The third layer of the architecture is represented by IBM Tivoli Directory Integrator. The IBM Tivoli Directory Integrator uses a Connector component to connect to the Password Storage and retrieve the passwords stored there. Once in the IBM Tivoli Directory Integrator, the passwords are decrypted and made available to the AssemblyLine that synchronizes them with other systems. The IBM Tivoli Directory Integrator can be deployed on a machine different than the Target System and Password Storage machines.

The next layer in the architecture (in the data flow direction) is represented by the systems whose passwords are synchronized with the Target System. The password synchronization AssemblyLine is responsible for connecting to these systems and updating the passwords there.

The Password Store Interface

A key element of the IBM Tivoli Directory Integrator password synchronization architecture is the Password Store Interface. The Password Store Interface mediates between the Password Synchronizer and the Password Store components. Password Store components implement this interface and Password Synchronizer components use this interface to interact with the Password Stores. This enables using any Password Synchronizer with any Password Store.

Also, the Password Store used by a Password Synchronizer can be easily changed when necessary. For example, a Password Synchronizer for IBM Tivoli Directory Server is deployed and configured to use the LDAP Password Store. After time it is decided that you need to use MQe Password Store. Then you need to configure the MQe Password Store, change a single property of the Password Synchronizer, and restart the IBM Tivoli Directory Server. New password changes are stored in MQ Everyplace. It is not necessary to install the solution again.

Architecture options

For simplicity, the previous diagram shows password interception on a single Target System. Actually, a password synchronization solution might need to intercept password changes on several Target Systems. This is where the layered password synchronization architecture brings additional value in terms of scalability and customization options:

In either (or both) of these previous approaches, it is possible to add, remove or change Target Systems in an already existing solution by focusing mainly on the new functionality without affecting the rest of the solution.

On the other end of the data flow, where passwords are updated in systems that you want to keep synchronized, the password synchronization architecture benefits from the inherent scalability of the IBM Tivoli Directory Integrator. Updating passwords on yet another system might be as easy as adding a new Connector in the password synchronization AssemblyLine.

In the case where the Target System is also one of the systems updated with the intercepted passwords from other systems, special care must be taken to avoid circular updates. The implementation on the IBM Tivoli Directory Integrator side must build logic that does not update a system with passwords intercepted on that same system.

Security

Public-private key infrastructure is used to provide secure transport and intermediate storage of password data.

The Password Store components use a public key to encrypt password data before sending it on the wire and storing it in the Password Storage. The IBM Tivoli Directory Integrator AssemblyLine or specialized Connectors have the corresponding private key and use it to decrypt password data retrieved from the Password Storage.

An additional layer of security is added by Password Store components supporting SSL.

Reliability

Functionality for preventing and dealing with possible password desynchronization is built into the password synchronization workflow.

The Password Synchronizer and Password Store components together provide functionality to deal with cases where an external storage system is not available or malfunctions.

The Password Store always reports to the Password Synchronizer whether or not the password was successfully stored into the Password Storage. The Password Synchronizer component can do the following to prevent or handle possible password desynchronizations:

Password Synchronizers

The following Password Synchronizers are currently available:

Password Synchronizer for IBM Tivoli Directory Server

The IBM Tivoli Directory Server Password Synchronizer intercepts changes to LDAP passwords in IBM Tivoli Directory Server 5.2 and 6.0.

Passwords in IBM Tivoli Directory Server are stored in the userPassword LDAP attribute. The Password Synchronizer intercepts updates of the userPassword LDAP attribute.

The IBM Tivoli Directory Server Password Synchronizer intercepts modifications of the userPassword attribute of entries of any object class.

Password updates are intercepted for the following types of entry modifications:

Note:
Deletion of entries (users) is not intercepted by the IBM Tivoli Directory Server Password Synchronizer even when the entry contains the userPassword attribute.
Note:
The userPassword attribute in IBM Tivoli Directory Server is multiple-valued. Users can have several passwords. The IBM Tivoli Directory Server Password Synchronizer intercepts and reports any change of any of the password values.

Supported platforms

The IBM Tivoli Directory Server Password Synchronizer is available for the IBM Tivoli Directory Server 5.2 and 6.0 on the following platforms:

Deployment and Configuration

For deployment and configuration of the IBM Tivoli Directory Server Password Synchronizer see IBM Tivoli Directory Server Password Synchronizer Deployment Instructions (readme_idspwsync_ismp.htm).

Using the Password Synchronizer

Two of the configuration properties of the IBM Tivoli Directory Server Password Synchronizer are of particular interest and directly affect the password synchronization logic:

syncBase
This property enables restricting the part of the directory tree where passwords are intercepted. The value specified is the LDAP distinguished name (dn) of the root of the tree whose entry passwords you want to intercept. Specifying "o=ibm,c=us", for example, results in intercepting the password update "cn=Kyle Nguyen,ou=Austin,o=IBM,c=US" and skipping password update of "cn=Henry Nguyen,o=SomeOtherCompany,c=US". Setting no value to this property results in the interception of password updates in the whole directory tree.
checkRepository
This property enables turning on or off the functionality that checks for availability of the Password Storage.

When this property is set to true, the Password Synchronizer first checks whether the Password Storage is available. If it is available, the password is changed in the directory, then the password is sent to the Password Storage. If the check indicates that the storage is not available, the LDAP operation (a part of which is the password update) is rejected on the IBM Tivoli Directory Server.

When the checkRepository property is set to false, the Password Synchronizer performs no checks for storage availability. The password update is performed in the directory first, then an attempt is made to store it in the Password Storage. If the password cannot be stored, a message is logged in the log file (pointed to by the logFile property) to indicate that password synchronization for this user failed.

Note:
The check for availability of the Password Storage works with all Password Store components.

Stopping the Proxy Layer

The IBM Tivoli Directory Server Password Synchronizer consists of two layers: an IBM Tivoli Directory Server plug-in which is hooked into the Server, and a Java(TM) Proxy Layer. The plug-in intercepts password updates and sends them to the Proxy Layer. The Proxy Layer instantiates the Password Store component on startup and transmits all password updates received by the plug-in to the Password Store.

The Proxy Layer is started automatically by the IBM Director Server when the IBM Tivoli Directory Server starts. However, it is not stopped when the IBM Tivoli Directory Server stops. The Proxy Layer must be stopped explicitly when the IBM Tivoli Directory Server is shut down.

If you do not stop the Java Layer explicitly, the IBM Tivoli Directory Server Password Synchronizer does not start properly the next time the IBM Tivoli Directory Server is activated.

Use the StopProxy utility included in the IBM Tivoli Directory Server Password Synchronizer to stop the Java Layer. It is a stand-alone Java application and its usage is described in IBM Tivoli Directory Server Password Synchronizer Deployment Instructions (readme_idspwsync_ismp.htm).

Changing the Password Store

The Password Store used by the IBM Tivoli Directory Server Password Synchronizer can be changed at any time after the initial deployment of the solution. See IBM Tivoli Directory Server Password Synchronizer Deployment Instructions (readme_idspwsync_ismp.htm) for instructions on how to change the Password Store.

Password Synchronizer for Sun ONE Directory Server

The Sun ONE Directory Server Password Synchronizer intercepts changes to LDAP passwords in Sun ONE Directory Server.

Passwords in Sun ONE Directory Server are stored in the userPassword LDAP attribute. The Password Synchronizer intercepts updates of the userPassword LDAP attribute.

The Sun ONE Directory Server Password Synchronizer intercepts modifications of the userPassword attribute of entries of any object class.

Password updates are intercepted for the following types of entry modifications:

Notes:
  1. Deletion of entries is not intercepted by the Sun ONE Directory Server Password Synchronizer even when the entry contains the userPassword attribute.
  2. The userPassword attribute in Sun ONE Directory Server is multiple-valued. Users might have several passwords. The Sun ONE Directory Server Password Synchronizer intercepts and reports any change of any of the password values.

Supported platforms

The Sun ONE Directory Server Password Synchronizer is available for the Sun ONE Directory Server 5.1 on the following platforms:

Deployment and Configuration

For deployment and configuration of the Sun ONE Directory Server Password Synchronizer see Sun ONE Directory Server Password Synchronizer Deployment Instructions (readme_sundspwsync_ismp.htm).

Using the Password Synchronizer

Two of the configuration properties of the Sun ONE Directory Server Password Synchronizer are of particular interest and directly affect the password synchronization logic:

syncBase
This property enables restricting the part of the directory tree where passwords are intercepted. The value specified is the LDAP distinguished name (dn) of the root of the tree whose entry' passwords you want to intercept. Specifying "o=ibm,c=us", for example, results in intercepting password update "cn=Kyle Nguyen,ou=Austin,o=IBM,c=US" and skipping the password update "cn=Henry Nguyen,o=SomeOtherCompany,c=US". Setting no value to this property results in the interception of password updates in the whole directory tree.
checkRepository
This property enables turning on or off the functionality that checks for availability of the Password Storage.

When this property is set to true, the Password Synchronizer first checks whether the Password Storage is available. If it is available, the password is changed in the directory, then the password is sent to the Password Storage. If the check indicates that the storage is not available, the LDAP operation (a part of which is the password update) is rejected on the Sun ONE Directory Server.

When the checkRepository property is set to false, the Password Synchronizer performs no checks for storage availability. The password update is performed in the directory first, then an attempt is made to store it in the Password Storage. If the password cannot be stored, a message is logged in the log file (pointed to by the logFile property) to indicate that password synchronization for this user failed.

Note:
The check for availability of the Password Storage works with all Password Store components.

Changing the Password Store

The Password Store used by the Sun ONE Directory Server Password Synchronizer can be changed at any time after the initial deployment of the solution. See Sun ONE Directory Server Password Synchronizer Deployment Instructions (readme_sundspwsync_ismp.htm) for instructions on how to change the Password Store.

Password Synchronizer for Windows

The Password Synchronizer for Windows intercepts password changes of user accounts on Windows NT(R), Windows 2000, Windows XP and Windows 2003 Server operating systems.

Password changes are intercepted in all of the following cases:

Deployment and Configuration

For deployment and configuration of the Windows Password Synchronizer, see IBM Tivoli Directory Integrator Password Synchronizer Plug-in for Windows (readme_winpwsync_ismp.htm).

Windows Password Synchronizer Workflow

Windows allows password filter plug-ins to register for notifications of user password changes. These plug-ins are invoked before the password change is committed by Windows. The purpose of these password filters is to validate the password. If any one of the registered password filters rejects the password change, Windows also rejects the password change.

The Windows Password Synchronizer plug-in registers as such a Windows password filter. The plug-in verifies that the Password Store is available. If the Password Store is not available the plug-in rejects the password change. If the Password Store is up and running the plug-in allows Windows to complete committing the password change. If, however, another password filter rejects the password change Windows rejects the password change and the plug-in will not synchronize the password change.

Windows has a notification mechanism which allows applications to get notified when a user password change has been committed by Windows. The Windows Password Synchronizer plug-in registers for this notification. This notification is not generated if Windows rejects a password change. Thus the plug-in notification for a committed password change is not invoked unless all password filters have approved the password and Windows has successfully committed the password change.

If the password change has been rejected by the Windows Password Synchronizer plug-in and if it has been initiated from the Windows user interface, an error box is displayed with contents similar to:

Windows cannot complete the password change for <user_name> because: 
The password does not meet the password policy requirements. 
Check the minimum password length, password complexity and password history requirements.

This is a standard message that is displayed by Windows when the password change is denied. The log files of the Password Synchronizer and the Password Store component indicate the actual reason why the password cannot be stored in the Password Storage.

Changing the Password Store

The Password Store used by the Windows Password Synchronizer can be changed at any time after the initial deployment of the solution.

To switch the Windows Password Synchronizer to use the LDAP Password Store:

  1. Make sure the LDAP Password Store is configured.
  2. Double-click on the file idiLDAP.reg placed in the install directory of the Windows Password Synchronizer.
  3. Click Yes to change the registry settings.
  4. Restart the machine.

To switch the Windows Password Synchronizer to use the MQe Password Store:

  1. Make sure the MQe Password Store is configured.
  2. Double-click on the file idiMQE.reg placed in the install directory of the Windows Password Synchronizer.
  3. Click Yes to change the registry settings.
  4. Restart the machine.

Password Synchronizer for Domino

The Domino HTTP Password Synchronizer intercepts changes of the Internet password (also known as HTTP password) for Notes users.

The following types of password changes are intercepted:

Administrative password resets
A user with the necessary rights (usually an administrator) changes his or another user's password without being prompted for the old password:
Normal user password changes
A user changes his own password and is prompted for the old password:

Supported platforms

The Domino HTTP Password Synchronizer supports Domino R6 and all platforms supported by Domino R6.

Deployment and configuration

The Domino HTTP Password Synchronizer can be deployed in the following modes:

For deployment and configuration of the Domino HTTP Password Synchronizer see readme_dominopwsync_ismp.htm.

Using the Password Synchronizer

Only certain password change mechanisms are intercepted

When using the Domino HTTP Password Synchronizer, be aware that only certain password change mechanisms are intercepted. These are the mechanisms listed previous:

Note:
Password changes performed through any other interfaces are not intercepted. For example, if passwords are changed through LDAP, or a Notes-Internet password synchronization is enabled, the Domino HTTP Password Synchronizer is not triggered and these password changes are not synchronized.
Administrative password resets

The Domino HTTP Password Synchronizer is triggered when a user's Person document is edited and saved and the Internet password field of the Person document has been changed.

When synchronizing this type of password change (administrative password reset), the Domino HTTP Password Synchronizer hooks into the internal Domino logic before the password change is committed in Domino. If the Password Synchronizer successfully stores the changed password in the Password Store, the password change is performed in Domino. If the Password Synchronizer cannot store the changed password in the Password Store (for any reason), the password change is not performed in Domino and all other changes to the Person document are also rejected.

Note:
This only applies for password changes performed through the Lotus Domino Administrator. After entering the new password value in the Internet password field, you must not switch from the Basics page of the opened Person document. If you switch to another page of the Person document before saving the changes, the password is hashed, the Domino HTTP Password Synchronizer is not able to get and no synchronization is triggered in this case.
Normal user password changes

The Domino HTTP Password Synchronizer is triggered after a user changes his own password through the Password Change Web form or through iNotes. In both cases an administration request document (Change HTTP password in Domino Directory) is posted in the administration requests database. The Password Synchronizer is triggered after a document of this type is successfully processed by the Administration Process in Domino. At this stage the password change is already committed in Domino. If the Password Synchronizer successfully stores the password change in the Password Store, this administration request is marked as processed, so the administration request is not processed again the next time the Password Synchronizer is triggered. If the Password Synchronizer cannot store the password change in the Password Store (for any reason), the administration request is not marked as processed, so the Password Synchronizer attempts to process the administration request again the next time it is triggered.

Note:
To enable the Change Password Web form, some setup is necessary in Domino (the Domino Configuration database DOMCFG.NSF must be created and session-based Web authentication must be enabled). For more information see the following articles in the Lotus Domino Administrator help: Creating the Domino Configuration database and Setting up session-based name-and-password authentication.

The component of the Domino HTTP Password Synchronizer that handles password change admin requests is a Domino agent named IDIPWSyncAdminRequestAgent. The IDIPWSyncAdminRequestAgent is a scheduled agent that is automatically (but not immediately) run after documents are created or changed in the administration requests database. It is the Agent Manager process that schedules what time after the actual document change that the agent is run. The Agent Manager checks two Domino Server parameters:

AMgr_DocUpdateEventDelay
Specifies the delay time, in minutes, that the Agent Manager schedules a document update-triggered agent after a document update event. The default is 5 minutes. The delay time ensures the agent runs no more often than the specified interval, regardless of how frequently document update events occur.
AMgr_DocUpdateAgentMinInterval
Specifies the minimum elapsed time, in minutes, between executions of the same document update-triggered agent. This lets you control the time interval between executions of a given agent. Default is 30 minutes.

The default values of these parameters mean that the agent is run 5 minutes after an admin request is created or changed, but no sooner than 30 minutes after a previous run of the same agent.

The AMgr_DocUpdateEventDelay and AMgr_DocUpdateAgentMinInterval parameters can be changed by editing the NOTES.INI file of the Domino Server (if the parameters are not specified there, you can add them, each on a separate line).

Note:
These parameters affect all document update-triggered agents and setting low values can result in decreased server performance.

Admin requests stay in the administration requests database for a certain amount of time after they have been posted or last changed. Default value is 7 days (more than any rational values for the AMgr_DocUpdateEventDelay and AMgr_DocUpdateAgentMinInterval parameters). Do the following to check or change the garbage collection interval:

  1. In Lotus Domino Administrator, select Files.
  2. Right-click the Administration Requests database.
  3. Select Properties.
  4. Click Replication Settings.
  5. Select Space Savers.

The value of interest is Remove documents not modified in the last # days.

When run, the agent processes in a batch all new password changes. It processes 5000 password changes at most. If more than 5000 password changes have been performed since the last run of the agent, it only processes 5000 password changes. The other password changes are processed during subsequent agent runs.

Another important Domino Server parameter that affects the behavior of the IDIPWSyncAdminRequestAgent is the Max LotusScript/Java execution time. This parameter has daytime and nighttime values that specify the maximum time an agent is enabled to run in the corresponding portion of the day. Defaults are 10 minutes for daytime and 15 minutes for nighttime. If the agent exceeds this timeframe, it is stopped, and the unprocessed password changes are processed in subsequent runs. Change these values by editing the Max LotusScript/Java execution time fields in the Server Document, section Server Tasks/Agent Manager. Note however that these settings affect all Java and LotusScript agents.

Secure password transfer

Secure communication is achieved by enabling SSL for the Web-based mechanisms for password change (editing Person documents through the browser, using the Change Password Web form and using iNotes).

When editing Person documents through the Lotus Domino Administrator client, communication is secured by enabling port encryption in Domino.

Refer to readme_dominopwsync_ismp.htm for information how to set up security.

The Proxy Process

After the password is intercepted (in any of the supported password change mechanisms), it is always passed to the Proxy Process of the Domino HTTP Password Synchronizer. The Proxy Process instantiates a Password Store and uses it to store the password data. The Proxy Process is a Java Domino Server task. It is started by the Domino Server on startup and is stopped when the Domino Server stops. If necessary, the Proxy Process can be stopped and started manually from the Domino Server Console:

To manually stop the Proxy Process, enter the following Domino Command: tell IDIPWSync quit

To manually start the Proxy Process, enter the following Domino Command: load runjava com.ibm.di.plugin.pwsync.domino.DominoProxy

You can check whether the Proxy Process is started by entering the following command on the Domino Console: show tasks

If the Proxy Process is started, a line for the IDI Password Sync task (which is the Password Synchronizer Proxy Process) appears in the list. For example: IDI Password Sync Listen for connect requests on TCP Port:19003

Synchronizing the access to the Password Store

Several password changes in Domino can be made at the same time from multiple users and from different interfaces. The Domino HTTP Password Synchronizer works with multiple threads of execution and attempts multithread access to the Password Store.

In cases when multithread access to the Password Store might be a problem (such as when MQe Password Store is used), you can synchronize the access to the Password Store. The configuration file of the Domino HTTP Password Synchronizer ididompwsync.props contains a property named proxy.syncStoreAccess. Set this property to true if you want to synchronize the access to the Password Store. Set this property to false if you want to enable multithread access to the Password Store.

Note:
It is recommended to set proxy.syncStoreAccess to true when using the MQe Password Store because MQ Everyplace QueueManagers are not thread-safe. You can safely use multithread access with the LDAP Password Store.
Changing the Password Store

The Password Store used by the Domino HTTP Password Synchronizer can be changed at any time after the initial deployment of the solution:

Password Stores

The following Password Stores are currently available:

LDAP Password Store

The LDAP Password Store provides the function necessary to store the intercepted user passwords in an LDAP directory server.

Supported Directories

The LDAP Password Store is available on the following directories:

Deployment and Configuration

For deployment and configuration of the LDAP Password Store, see LDAP Password Store Installation and Setup (readme_ldapstore_ismp.htm).

Using the Password Store

For each user whose password has been intercepted, the LDAP Password Store maintains an LDAP entry in the storage LDAP directory (the container where the storage entries are added and modified is specified by the suffix property of the LDAP Password Store).

The entry kept in the storage directory always contains the passwords currently used by the original user on the Target System. To achieve this, the LDAP Password Store updates the state of the entry in the storage directory whenever the LDAP Password Store receives notification for password update from the Password Synchronizer.

The LDAP Password Store receives the following data from the Password Synchronizer:

User Identifier
The user identifier is used for the relative distinguished name of the entry stored in the LDAP directory. For example, if the user identifier is "john" and the suffix property value is "dc=somedc,o=ibm,c=us", then the distinguished name of the entry stored is "ibm-diUserId=john, dc=somedc,o=ibm,c=us".

Special attention is necessary when the LDAP Password Store is used with the IBM Tivoli Directory Server Password Synchronizer or with the Sun ONE Directory Server Password Synchronizer.

The Password Synchronizer reports the LDAP distinguished name of the user for which the password has been changed. For example, "cn=john,o=somecompany,c=us". The LDAP Password Store takes the first element of the distinguished name ("john") to construct the distinguished name of the entry on the storage LDAP directory, for example, "ibm-diUserId=john, dc=somedc,o=ibm,c=us". Therefore the context information (department, company, country, and so forth) is lost. If there are two individuals on the Target System with equal names but in different departments, for example, "cn=Kyle Nguyen,ou=dept_1,o=ibm,c=us" and "cn=Kyle Nguyen,ou=dept_2,o=ibm,c=us", they are indistinguishable for the Password Store, and the Password Store acts as if they represent the same person.

Type of password modification and List of password values
The type of password modification indicates whether the password values have been replaced, or new values have been added, or certain values have been deleted. Using this information and the list of passwords representing the change, the Password Store duplicates the change on the entry in the storage directory.

The type of password modification makes sense only when the password can have multiple values (IBM Tivoli Directory Server, Sun ONE Directory Server). When the passwords on the Target System are single-valued (Windows), the password modification type is always replace.

When the password (with all its values) is deleted from the Target System, the entry in the storage directory is modified so that it does not have value for the LDAP attribute used to store the passwords.

Possible password retrieval from IBM Tivoli Directory Integrator

Here is a possible mechanism for retrieving passwords stored in an LDAP Server by the LDAP Password Store:

An EventHandler is configured to listen for changes in the LDAP Directory used for storage. Whenever the EventHandler detects that an entry has been added or modified in the Password Store container, it starts an AssemblyLine, passing it identification of the modified entry. The AssemblyLine uses an LDAP Connector to read the modified entry, then decrypts the updated password values and propagates the values to systems that must be kept synchronized.

MQ Everyplace Password Store

MQ Everyplace Password Store (MQe Password Store) provides the function necessary to store user passwords into IBM WebSphere MQ Everyplace and transfer user passwords from MQ Everyplace to IBM Tivoli Directory Integrator.

The MQe Password Store package consists of the Storage Component and the MQe Password Store Connector. The Storage Component is actually the Password Store invoked by the Password Synchronizer. The MQe Password Store Connector is a specialized Connector on the IBM Tivoli Directory Integrator side that can retrieve passwords stored into MQ Everyplace.

Solution structure and workflow

Two MQ Everyplace QueueManagers are instantiated and configured: one on the Target System, and one on the IBM Tivoli Directory Integrator machine.

On the QueueManager on the IBM Tivoli Directory Integrator, a local queue is defined. On the QueueManager on the Target System, an asynchronous remote queue that references the local queue on the IBM Tivoli Directory Integrator QueueManager is defined. A connection and listener objects are defined in the QueueMangers to enable network communication.

The following is the workflow for the MQe Password Store:

  1. The Password Synchronizer intercepts a password change and sends it to the Storage Component.
  2. The Storage Component wraps the password into an MQe message and sends the message to the remote queue on the local QueueManager.
  3. The MQe QueueManager on the Storage Component automatically sends the message to the QueueManager on the IBM Tivoli Directory Integrator.
  4. The MQe Password Store Connector connects to the local QueueManager and reads the password update messages from the local queue.

Supported WebSphere MQ Everyplace version

The MQe Password Store contains WebSphere MQ Everyplace v.2.0.0.4 embedded. No separate installation of WebSphere MQ Everyplace is necessary.

Part of the MQe Password Store deployment and configuration is the instantiation and configuration of the MQ Everyplace QueueManagers.

Once the MQe QueueManagers are instantiated and configured it is not recommended to change their configuration. If a change is necessary, the preferred method is to delete the QueueManager and recreate it again following the MQe Password Store deployment instructions. If however, for any reason, you are going to use an MQe administration tool to change QueueManagers settings, make sure this tool is compatible with QueueManagers created with MQ Everyplace v.2.0.0.4.

Deployment and Configuration

For deployment and configuration of the MQe Password Store see MQ Everyplace Password Store Installation and Setup (readme_mqepwstore_ismp.htm).

Using the Password Store

The LDAP Password Store maintains state of the user's passwords. It keeps the passwords in the LDAP storage entries up to date with the passwords of the corresponding users. In contrast, the MQe Password Store does not maintain state of the user's passwords; it just reports the changes. Each message tells how the passwords of a user have changed, not what the user's password values are.

This difference is important for the design of the AssemblyLine that propagates the password changes to other systems, especially when multiple valued passwords are supported. In the case of the LDAP Password Store, the AssemblyLine must replace the passwords in the systems it keeps synchronized with the passwords read from the LDAP storage. When MQe Password Store is used, the AssemblyLine must duplicate just the reported password change on the other system.

Each MQe message contains the following information:

User Identifier
The user identifier is the string value that identifies the user in the Target System (for LDAP Servers this is the LDAP distinguished name; for Windows this is the user account name). The AssemblyLine must locate the users on the systems that are synchronized based on this user identifier.
Note:
When the Target System is an LDAP Server, the MQe Password Store reports the whole LDAP distinguished name as user identifier (for example, "cn=john,o=somecompany,c=us"), in contrast to the LDAP Password Store, where only the value of the first element ("john") is used.
Type of password modification and List of password values
The type of password modification might be one of replace, add or delete and correspondingly indicates that the password values have been replaced, that new values have been added, or certain values have been deleted.

add and delete make sense only when multiple password values are supported by the Target System. If the Target System does not support multiple passwords for a single user, the type is always replace.

Depending on the type of password modification, the list of password values means the following:

replace
The passwords for the specified user are replaced with the passwords specified in the list of password values
add
The passwords from the specified list of password values are added to the user's passwords (for example, new passwords are created for this user and the old ones are still in effect)
delete
The passwords from the specified list of passwords values are removed from the user's passwords (for example, some of the user's passwords are deleted and the user can no longer use them)
Note:
The type of password modification refers to the password attribute, not to the entry or user for which the password is modified. Thus add means that new password values are added to the user's password attribute and not that a new user is added in the system. On the other hand, when a new user is added in the system, it is appropriate to receive modification type replace because of the way the user password is internally set in the Target System.

Availability issues

The QueueManager on the Storage Component is automatically started and stopped when the Storage Component is started and stopped.

The QueueManager on theIBM Tivoli Directory Integrator is automatically started and stopped when the MQe Password Store Connector is correspondingly initialized and stopped. This means that the QueueManager on the Storage Component is available only when the Storage Component is available and the QueueManager on the IBM Tivoli Directory Integrator is available only when the AssemblyLine with the MQe Password Store Connector is running.

There are three interesting cases regarding solution components availability:

Both QueueManagers are available (the Password Synchronizer is running and the AssemblyLine is running)
Each new intercepted password is immediately transferred between the QueueManagers and retrieved by the MQe Password Store Connector.
Only the QueueManager on the Storage Component is available (the Password Synchronizer is running and the AssemblyLine is not running)
Each new intercepted message is stored on the local disk by the Storage Component QueueManager. When the AssemblyLine is started, all messages stored offline are automatically transferred to the QueueManager on the IBM Tivoli Directory Integrator and the MQe Password Store Connector retrieves them from there.
Only the QueueManager on the IBM Tivoli Directory Integrator is available (the Password Synchronizer is not running and the AssemblyLine is running)
There are no new messages in this case because the Password Synchronizer is not running. When the Password Synchronizer is started, all messages stored previously on the Storage Component QueueManager are automatically transferred to the QueueManager on the IBM Tivoli Directory Integrator and the MQe Password Store Connector retrieves them from there.

No messages (password updates) are lost regardless of the availability of the Password Synchronizer and the MQe Password Store Connector and when they are started and stopped. However, for message transfer to take place, both QueueManagers must be available at the same time for at least a few minutes.