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.
The components that make up a password synchronization solution are:
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.
The following specialized password synchronization components are currently available:
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.
There are several layers in the IBM Tivoli Directory Integrator Password Synchronizer 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.
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.
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.
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.
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:
The following Password Synchronizers are currently available:
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:
The IBM Tivoli Directory Server Password Synchronizer is available for the IBM Tivoli Directory Server 5.2 and 6.0 on the following platforms:
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).
Two of the configuration properties of the IBM Tivoli Directory Server Password Synchronizer are of particular interest and directly affect the password synchronization logic:
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.
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).
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.
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:
The Sun ONE Directory Server Password Synchronizer is available for the Sun ONE Directory Server 5.1 on the following platforms:
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).
Two of the configuration properties of the Sun ONE Directory Server Password Synchronizer are of particular interest and directly affect the password synchronization logic:
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.
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.
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:
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 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.
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:
To switch the Windows Password Synchronizer to use the MQe Password Store:
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:
The Domino HTTP Password Synchronizer supports Domino R6 and all platforms supported by Domino R6.
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.
When using the Domino HTTP Password Synchronizer, be aware that only certain password change mechanisms are intercepted. These are the mechanisms listed previous:
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.
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.
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:
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).
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:
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 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.
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
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.
The Password Store used by the Domino HTTP Password Synchronizer can be changed at any time after the initial deployment of the solution:
proxy.storeClassName=com.ibm.di.plugin.pwsync.LDAPPasswordSynchronizerThe class com.ibm.di.plugin.pwsync.LDAPPasswordSynchronizer is included in the proxy.jar file shipped with the LDAP Password Store.
proxy.storeClassName=com.ibm.di.plugin.mqe.store.MQePasswordStoreThe class com.ibm.di.plugin.mqe.store.MQePasswordStore is included in the mqepwstore.jar file shipped with the MQe Password Store.
The following Password Stores are currently available:
The LDAP Password Store provides the function necessary to store the intercepted user passwords in an LDAP directory server.
The LDAP Password Store is available on the following directories:
For deployment and configuration of the LDAP Password Store, see LDAP Password Store Installation and Setup (readme_ldapstore_ismp.htm).
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:
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.
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.
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 (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.
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:
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.
For deployment and configuration of the MQe Password Store see MQ Everyplace Password Store Installation and Setup (readme_mqepwstore_ismp.htm).
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:
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:
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:
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.