Transparent Password Synchronization Architecture
Transparent password synchronization, triggered by a native password change on a monitored system works as follows:
- User: decides to change his password(s) or has been prompted
to during the login process.
- User: enters his login ID, current password and desired value.
- Login server:
(e.g.,
Windows NT, Active Directory (32-bit, 64-bit), Sun LDAP, IBM LDAP,
Oracle Internet Directory, Unix (various), OS/390 and OS/400
) validates password
quality internally, then calls a P-Synch® library to further validate
password quality.
- P-Synch library: contacts the
P-Synch server; establishes
an encrypted connection; forwards a request for password policy
validation.
- P-Synch server: validates password quality; returns result.
In the event of an attempted policy violation, P-Synch may send
a message directly to the user by e-mail or a
Windows pop-up message; may write a call tracking system ticket and so on.
- Login server: updates the user's
password field internally, calls the P-Synch library to notify it
of the successful change. Note that a failure to meet the P-Synch
policy will normally block the initial password change from happening.
- P-Synch library: contacts the
P-Synch server; establishes
an encrypted connection; forwards a request for password synchronization.
- P-Synch server: queues up the new password for synchronization.
- P-Synch server: resolves the single queued event to a list of
passwords that must be set for this user (one per account).
- P-Synch server: administratively sets the user's passwords
on each system to the new value.
- P-Synch server: in the event of failure, re-queues and retries; may send the user one or more e-mails to notify of the problem; may write a ticket to a call tracking system to alert someone of a problem.
This is implemented on the network with the following components:
Transparent synchronization architecture diagram (1)