IDM 4.5.02, latest AD shim. 2008 functional level AD Domain.

So this is interesting. I need to test locking an account by resetting
the password.

Using validator, I set up a test, set a test user account to a known
password (Side note: Random/different password in Validator? Set time
in CTIME into a variable, set password as Testing${CTIME-Now})

So I assert that the change made it in. Then I kick off my event storm
to cause the password to be reset.

I see the first password change sync. Nice and quick. Less than a
second round trip.

Second password change comes within 10 seconds (polling a DB table, so
that is most of the delay).

But then I assert password is now different in IDV, yep, it is changed.
(After all, I saw the password change in trace flow to AD).

Assert password in AD is different, takes up to 3 minutes. Even though
I saw the event flow through the shim within seconds.

Why is it taking 3 minutes?

I am pointing my RL at a specific DC by DNS name (But NOT using the
domain DNS entry, I know that is a round robin address). My Validator
is pointing at the same DC.

I ask here, not in Validator forum, since this is a sync issue, I am
just discovering it with Validator.

While this was happening I tried an LDAP browser (same DC by DNS name),
and for the first 2-3 minutes I can use the old password, even though I
saw the change go by already.

Finally it changes, but multiple minutes later. Now only new password

As I write this, I wonder, is it possible that the thingy in AD that
eDir was supposed to get, allowing the previous password to work so
password changes do not get intruder locked by your phone, etc.

But I thought that just excluded Password - 1 from lockout counts? Not
that the old one continues to work. Hmm, I wonder if the new one works
at the same time as the old one.