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 TDI. As a result, implementing the solution that intercepts the passwords and makes them accessible from IBM TDI 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 TDI 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 TDI AssemblyLines using Connectors in Server Mode to automate the process of synchronization. For example, an AssemblyLine 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 an AssemblyLine using a Timer loop 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 TDI . Once the IBM TDI can access the intercepted passwords through its Connectors, the whole flexibility and openness of the IBM TDI architecture can be leveraged in organizing the process of password retrieval and propagation to other systems.
When NOT to deploy a Password Synchronizer
There are a number of situations in which it is unwise to use Password Synchronizers, because it would make the solution unneccesarily complex. In particular, in cases involving the Sun Directory Server Password Synchronizer and IBM Directory Server Password Synchronizer simpler methods can be deployed.
As a rule of thumb, Password Synchronizer should be deployed only if hashed password values are not usable outside the directory. Both IBM Directory Server and Sun Directory Server support password encryption where password values are encrypted before they are stored in the directory. Password encryption uses either a one-way or a two-way cryptographic transformation. One-way transformations (for example, hashing with SHA-1 or MD-5) are not reversible. This means that plaintext value cannot be obtained from a one-way encrypted password. The strength of a Password Synchronizer is that it catches the plaintext password before it is hashed and stored in the directory. If hashed values can be used by the destination repository, for example when both the source and the destination systems support the same hashing schemes, synchronization could be done via LDAP and Password Synchronizer is not necessary. As a corollary, we do not need a Password Synchronizer to synchronize passwords between instances of IBM Directory Server and Sun Directory Server. The reason is that both directories support the same set of hashing algorithms for passwords. In those cases you could simply copy passwords between the two instances via LDAP. Alternatively if all we need is to authenticate against an IBM Directory Server with credentials stored in a Sun Directory Server, we can use the pass-through authentication option supported by IBM Directory Server.
Issues with Directory Server replication
In a replication topology it is recommended to deploy Password Synchronizers on all master instances: When replication is configured, changes are propagated to replication consumers using LDAP operations. If a Password Synchronizer is deployed on a consumer, it will also intercept LDAP operations triggered by replication. If the Password Synchronizer rejects a password coming from replication, the replication process will fail. To avoid such situations, deploy Password Synchronizers on all replication masters, so that passwords could be rejected before they even get into the directory. Be aware that when a password is set on a supplier node in a replication topology, the Password Synchronizers on all associated consumer nodes will synchronize the password value to the Password Store. As a result the same password will be sent to the Store multiple times. One way to avoid this is to configure the directory to use password hashing. Password Synchronizers ignore hashed passwords, so Password Synchronizers on consumers will ignore the already hashed password value, which they receive from the replication supplier.
Hashed Passwords
The Password Synchronizer ignores hashed password values. This means that only plaintext passwords will be synchronized. The Password Synchronizer would receive hashed passwords in the following cases: