In order to sync password changes that occur in Active Directory, we require a password filter plug-in to be installed on all Domain Controllers. This is needed so the clear-text password can be intercepted before it is hashed by Active Directory. This clear-text password is then played back to 389 as a password change over a SSL encrypted LDAP connection. This works fine, but many Active Directory administrators do not want to install anything extra on their Domain Controllers. Password changes that originate in 389 DS can by synchronized to AD just fine over a SSL encrypted LDAP connection without needing anything extra installed on the Domain Controllers.
We can avoid the need for a password filter plug-in if we use a pass-through authentication mode. If a simple bind operation against 389 DS fails for a synchronized user, we would do a pass through bind against Active Directory with the password that the client presented to us. If the bind operation against Active Directory succeeds, we can assume that the password was changed in Active Directory and 389 DS would locally hash the password and store it.
One hole that I see in this solution is that a user could change their password in AD, then continue to use their old password against DS until they first try to use their new password. If we can find a way to have Active Directory notify us when a password is changed (we don't need the password itself, we just need to know it changed), we could eliminate this hole by setting a flag in the user entry whose password has changed. This flag would require the user entry to use pass through authentication to Active Directory so we can capture the new password. Upon a successful pass through bind, we would capture the new password and clear the flag, which would allow subsequent binds to just use the locally stored password.
We need to monitor the PasswordLastChanged attribute in AD.
Metadata Update from @dpal:
- Issue set to the milestone: FUTURE
to comment on this ticket.