Architecture
The architecture diagram below shows the basic elements of transparent password synchronization. In the figure, a user changes their password natively on some system (most commonly a Windows workstation connected to an AD domain). A trigger installed on this system – in the case of an AD DC, this is a password filter DLL – contacts a Bravura Pass server when the password change happens, typically via a load balancer.
Two calls are made to Bravura Pass :
User X on system Z wishes to set their password to value Y. Is that acceptable?
Bravura Pass tests this combination against the password policy that applies to the user .
The password, which may have been accepted by the trigger system, may be rejected by Bravura Pass . In this case, the original password change is terminated: the new password is not committed anywhere and the user gets an error message.
Password quality validation must be performed by Bravura Pass as it has access to data, such as password history (unlimited, not just last N) and dictionaries, which enable it to enforce more robust rules than the trigger system.
The process is fault-tolerant. Inability to contact Bravura Pass is usually configured to cause passwords to be accepted.
Password value Y has been committed locally, on system Z, for User X. Please initiate synchronization if required.
Bravura Pass looks up the user’s other accounts (on system Z or elsewhere).
Bravura Pass connects to each system, resetting X’s password administratively to Y.
In the event an account password change fails on one of the user's synchronized systems, the password remains changed on all the user's systems that worked and Bravura Pass re-queues and retries the password change on any system that failed until it falls out from the queue. Additionally, Bravura Pass may be configured to send the user one or more e-mails to notify of the problem and/or create a ticket on an incident management system to alert someone of the synchronization problem.
Transparent synchronization architecture
