Idsyncwin does not invalidate old passwords

Question

I am using Identity Synchronization for Windows (part of DSEE 11g) to replicate MSAD accounts into an organization maintained in DSEE, one-way. This works acceptably, except for one nit, which may be a problem to complete the POC demonstration: a change of user password in MSAD does not propagate into DSEE reliably.
To be more specific, when the password is changed in Active Directory, ISW does detect the change and sets dspswvalidate:true as is expected. If the DSEE user logs in with the new MSAD password, this password is validated against MSAD, succeeds, and is saved into DSEE. Likewise, login with a random password fails as expected.
However, if the user logs in with his old DSEE password, the validation against MSAD is logged as successful (which is apparently wrong), but the old DSEE password remains in place. The dspswvalidate flag is cleared and the user no longer has a chance to log in with a Windows password - the old DSEE password remains in place.
I see that when provisioning new users, ISW can place an invalid string into userpassword attribute... can it do the same when it detects changes in the upstream MSAD data, so the user has no possibility to log in with an obsolete password?
Since the ISW is a bit of esoteric and old product with little change from DS5.x times (though works fine with current DSEE and MSAD), possibly a solution would be to make some plugin for DSEE that would detect changes to the dspswvalidate flag and invalidate a password?.. Any ideas how to do this, if all else fails?
Thanks in advance,
//Jim Klimov

Answer 1

So... status update: the problem has been traced to MSAD - the domain controllers trust both the user's new password and the previous password for 5 minutes, which leads to DSEE testing the old passwords if the clients request it to (i.e. regular mail checks), trusting them and saving them for posterity (and removing the flag to verify passwords via MSAD).
The Windows team was not able to remove this behaviour from domain controllers. It is also probably infeasible to change their password-changing procedure to change it twice (so as to forget the previous password completely), or to instantly (programmatically?) log in to DSEE via convergence or ldapsearch or whatever with the new password, or to manually change the email password as well - especially when end-users can change their domain passwords too.
So the problem remains: old passwords are verifiable via MSAD and thus trusted by DSEE, so for example regular messaging tasks running on behalf of users might practically prevent propagation of updated passwords from MSAD domain into DSEE/CommSuite.
One solution that I see is to have DSEE (maybe via its ISW plugin) not remove the dspswvalidate flag for a configurable timeout after it first detected the password-change event on another directory source. This way for some 10 minutes (for example) after the MSAD-initiated password invalidation, DSEE would re-validate against the domain, ultimately making sure that the saved-to-trust password is the new one.
Another idea is to test the user-provided cleartext password against (a copy of) the old DSEE userPassword hashed value, and not save the password if it is positive against both the MSAD domain and old DSEE password.
Both of those ideas rely on changes to the ISW plugin which we can not do to the closed-source program.
A bolt-on solution might be to make a script that runs every minute from crontab, detects new DSEE invalidations and saves a timestamp. Then for those example 10 minutes it would restore the requirement to validate against MSAD, if it detects the invalidation flag cleared during this time. I can foresee how this would NOT work and increase helpdesk calls, with lags upon logins after the password change, on-and-off trust of DSEE to one or another password, and mostly with automated email tasks firing within that minute between script runs so that the password change event, setting of the flag, validation of old password and clearing of the flag all happen before the bolt-on script would detect that anything happened.
MAYBE though, it can parse cn=changelog for a verifiable history of events to detect appearances of the validation flag - even if it has been cleared by the time the script runs...
Still, the bolt-on sounds like an unreliable solution, though doable.
Are there any other ideas or practical advices, remaining withing the constraints of MSAD + DSEE + IdSyncWin? (Implementation of IAMS in particular, to unify this and other identity management is considered, but as a separate project and purchase - so some solution is needed for what they have today)
Thanks,
//Jim Klimov