The PasswordSync feature keeps user password changes made on Windows Active Directory domains synchronized with other resources defined in Identity Manager. PasswordSync must be installed on each domain controller in the domains that will be synchronized with Identity Manager. PasswordSync must be installed separately from Identity Manager.
PasswordSync consists of a DLL (lhpwic.dll) that resides on each domain controller. This DLL receives password update notifications from Windows, encrypts them, and sends them over HTTPS to the PasswordSync servlet. The PasswordSync servlet is located on the application server running Identity Manager.
Using HTTPS is preferred, but HTTP is also supported.
The PasswordSync servlet translates the notification into a format Identity Manager can understand. The servlet then sends the password change (still encrypted) to Identity Manager using one of the following methods:
Direct method. The servlet communicates the password change directly to Identity Manager using native Identity Manager classes. (See What is PasswordSync?.)
The direct connection method is only recommended for smaller, less complex environments that only require message delivery to one system, and that do not require guaranteed message delivery. (If direct message delivery fails for some reason, the message will be lost. Back up delivery is not possible.)
JMS method. The servlet sends the password information to Identity Manager using JMS (Java Message Service). With JMS, the servlet submits password changes to the JMS Message Queue. Separately, Identity Manager’s JMS Listener Resource Adapter checks the Queue for new messages. If a password change message is found waiting on the Queue, the JMS Listener Adapter takes the message off the Queue and imports it into Identity Manager. (See Figure 11–2.)
The JMS method is recommended for more complex environments that have a high volume requirement, need messages delivered to multiple systems, and require guaranteed message delivery. The JMS Message Queue can be made highly available. As long as a message gets into the queue, if message delivery to Identity Manager should fail, the queue will keep the change until the message can be delivered to Identity Manager.
You must install and configure JMS separately.
Figure 11–1 diagrams a direct connection. In this configuration the PasswordSync servlet sends update messages directly to Identity Manager.
Figure 11–2 diagrams a JMS connection. In this configuration the PasswordSync servlet sends update messages to the JMS Message Queue. Identity Manager’s JMS Listener Resource Adapter periodically checks the Queue (indicated by the light blue arrow in the diagram) for new messages. The Queue responds by sending the messages to Identity Manager (indicated by the dark blue arrow).
When Identity Manager receives a password change notification, it decrypts it and processes the change using a workflow task. The password is updated on all of the user’s assigned resources, and an SMTP server sends an email to the user, notifying the user of the status of the password change.
Windows only sends out an update notification if a password change is successful. If a password change request does not meet the domain’s password policy, Windows will reject it and no synchronization data will be sent to Identity Manager.
Figure 11–3 shows Identity Manager initiating a workflow and sending email to the user after receiving a password update notification.
PasswordSync discards all account change notifications for account names that end in a $ (dollar sign). Account names that end in a $ are assumed to be Windows computer accounts. Any user account names that end in a dollar sign will not be forwarded to Identity Manager.