The Domino HTTP Password Synchronizer modifies the "names.nsf" database, adding custom Java agents and custom code in certain hooks.
The code in these hooks is executed by Domino when a Person document is saved in "names.nsf". This code retrieves the http password before it is hashed and sends the password value to the Password Synchronizer Proxy Process using custom Java code.
The Domino HTTP Password Synchronizer modifies the administration requests database "admin4.nsf" by adding a custom Java agent. The agent is configured as a scheduled agent that is triggered after documents are created or modified in the administration requests database "admin4.nsf". The agent is not triggered immediately after a document is created/modified in "admin4.nsf", but after a 5min - 30min interval, depending on a decision made by the Agent Manager process in Domino. When triggered, the agent searches the admin request for successfully processed "Change HTTP password in Domino Directory" administration requests, retrieves the new passwords from these requests and sends the password data to the Password Synchronizer Proxy Process.
When using the Domino HTTP Password Synchronizer, be aware that only certain password change mechanisms are intercepted. These are the mechanisms listed previous:
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.
A Proxy Process is started by Domino when the Domino Server is started. This Proxy Process is configured to instantiate a Password Store (LDAP, JMS, and so forth). The Proxy Process accepts TCP/IP connections, receives user id and password data and invokes the Password Store to store this data.
Custom code is placed in the "Person" form in the "names.nsf" database.
When the Person document is saved, this code is executed on the client (Lotus Domino Administrator). If the http password is changed, the following sequence of actions is performed:
Custom code is placed in the "Person" form in the "names.nsf" database. This code is executed on the Domino Server:
In this scenario the plain text password value is sent from the browser to the Domino Web Server when the web form is submitted. In order to protect the password on the wire, SSL is enabled on the Domino Web Server and users will use the HTTPS protocol from the browser.
Change of the HTTP password through the Password Change web form or through iNotes results in a "Change HTTP password in Domino Directory" admin request posted in the "admin4.nsf" database. The Admin Process processes this requests and changes the password in the user's Person document.
The password synchronizer adds a custom Java agent in the "admin4.nsf" database. After an administration request document or a reply to an administration request document is added to the "admin4.nsf" database, the Java agent is scheduled to start by the Agent Manager. The Java agent is not started immediately but after some configurable interval chosen by the Agent Manager (usually between 5 and 30 minutes after a document is posted). When the agent is run it performs the following actions:
are of type "Change HTTP password in Domino Directory"; and
have already been processed successfully by the Domino Admin Process, that is, have a reply document attached that confirms that Domino has successfully changed the password (if a password change request has not been processed yet, or has not been processed successfully, then the password change has not been applied and thus there is no need for the password synchronizer to report it); and have not already been processed successfully by the agent on a previous run of the agent.
The user identifier and the new password are retrieved and sent to the Proxy Process, which in turn sends them to the Password Store.
If the Password Store returns that the password has been successfully stored, the admin request is marked as processed, so the agent would not process it again on the next run. If the password has not been successfully stored, the document is not marked as processed, so the agent will process it again on the next run.
In this scenario the plain text password value is sent from the browser to the Domino Web Server when the web form is submitted. In order to protect the password in transit, SSL is enabled on the Domino Web Server and users will use the HTTPS protocol from the browser.
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.
For instructions on how to configure port encryption for Domino, see Setup of the Domino plug-in (specifically step 8).