The Password Synchronizer for Windows intercepts password changes of user accounts on Windows operating systems.
Password changes are intercepted in all of the following cases:
The IBM TDI Password Synchronizer plug-in propagates the changes to a repository (Password Store) before the Windows system changes the password.
The IBM TDI Password Synchronizer stores the user password in a Password Store (LDAP server, JMS Password Store).
The change is later propagated to other servers by an IBM TDI AssemblyLine. After the password is successfully stored in the Password Store, control is returned to the Windows system and the user password is modified.
To synchronize passwords from a single machine, install the Password Synchronizer on the Windows standalone machine.
To synchronize password changes from a Windows XP, Windows 2003 or Windows 2008 domain, install the Password Synchronizer on all domain controllers for the domain with which we want to synchronize.
Bob logs onto the windows machine, presses Ctrl+Alt+Delete, and requests a password change. That password change is intercepted by the Password Synchronizer, then delegated to the associated Password Store (LDAP Password Store, JMS Password Store). If the Password Store confirms that the password was successfully stored, then the password change takes place on the native Windows machine, whether it is a standalone machine or a domain controller. If the Password Store indicates that the password was not stored, then the password change on the native Windows machine is denied.
Password change requests to Active Directory through LDAP/JNDI are also intercepted and handled by the Password Synchronizer.
The Windows Password Synchronizer intercepts a password change before the change is actually committed internally by Windows and Active Directory. The Password Synchronizer passes the new password to the Password Store.
If the Password Store indicates that the password is stored successfully, the Password Synchronizer enables the password change to be committed in Windows.
If the Password Store indicates that the password is not stored, the password change is rejected on the Windows machine. If the password change has been performed from the Windows user interface, an error box is displayed with contents similar to:
Windows cannot complete the password change for user_name because: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.
This is a standard message that is displayed by Windows when the password change is denied. The log files of the Password Synchronizer and the Password Store component indicate the actual reason why the password cannot be stored in the Password Storage.
On each successful password change the Password Synchronizer sends the full name of the user (the "displayName" attribute from Active Directory) to the Password Store. Currently the JMS Password Store ignores this extra data. The LDAP Password Store writes the additional information to the extended data attribute of the user entry (by default the extended data attribute is named "ibm-diExtendedData").
The Password Synchronizer returns the sAMAccountName of the user whose password has been changed. This name is unique for each Windows Domain but it is not unique for the Domain forest. In order to retrieve the rest of the user attributes, additional lookups need to be done using the provided sAMAccountName as link criteria.
The Windows Password Synchronizer provides filtering functionality. Filtering affects only whether a password change is sent to the password store and not whether the Windows domain accepts or rejects the password change. If the user filter accepts a user, the password changes for that user are sent to the password store. Otherwise, password changes for that user are not sent to the password store for that user.
The user filter makes decisions based on two factors, or criteria:
Group membership deals with whether a user is a member of some Windows group. The user filter does not recognize nested groups, so if a user is a member of group A, which is nested into group B, then the user will not be deemed member of group B.
DN matching deals with whether a DN suffix matches the Distinguished Name of a user. For example if the user has a Distinguished Name cn=myuser,ou=myou,dc=mydc,dc=com it is matched by the DN suffix dc=mydc,dc=com but not by dc=mydc.
The user filter allows include and exclude rules of both group membership and DN matching. For example the user filter can be configured to accept all users which are members of a certain Windows group (include form) but not members of some other Windows group (exclude form).
Group membership and DN matching in both rules (include/exclude) can be freely combined. However, there is one specific limitation. Exclude rules always have higher priority than include rules. So for example if a user is included by DN matching but excluded by group membership, the user will not be accepted by the user filter.
To preserve backward compatibility, if no include form is specified (neither group membership, nor DN matching), the default form is include all. Inversely this also implies that if no exclude form is specified (neither group membership, nor DN matching), the default form is exclude none.
Here are some examples to help clarify the filtering mechanism:
The user filter of the Windows Password Synchronizer is configured using 4 string values in the plug-in configuration file to define the include and exclude rules.
All of the above property string values must be lists, with tokens separated by semicolons. Redundant white-spaces are not allowed. The group lists must include only names of existing Windows groups. Matching of a DN suffix against a Distinguished Name is performed by a simple case-insensitive string comparison - no special treatment is provided for white-spaces. For example, the DC=COM suffix matches the cn=myuser,dc=mydc,dc=com Distinguished Name, but the dc = com suffix does not.
If the user filter mechanism encounters an issue (for example an invalid group name in its configuration), an error message is logged and the Windows Password Synchronizer acts as if the filter has accepted the user. If the user filter decides to not accept a user, a message stating that is logged.
The configuration of the user filter is read again on each password notification, so changes to the configuration have immediate effect - there is no need to restart the Windows operating system for the changes to the user filter to be taken into account.
The user filter configuration of the Windows Password Synchronizer is sensitive to modifications of the Windows groups, involved in the configuration. If some of the following changes occur, the Windows Password Synchronizer must be restarted (which requires restart of the operating system):
Attention: The user filtering feature of the Windows Password Synchronizer will function properly only on machines that are part of a Windows domain. Workgroup machines will not be able to use user filtering. If you configure user filtering on a workgroup machine, the plug-in will log an error message like the following on every password change and will send the change to the password store, no matter the provided configuration:
User filtering failed: The specified domain either does not exist or could not be contacted.Note that if no user filtering configuration is supplied, the plug-in will function normally and no error will be logged (because no filtering is performed).