RODCs, Account Lockouts, and WAN-offline behavior

So in playing around in the lab this week, I came across a behavior that I wasn't aware of. Apparently it was blogged on the AskDS blog back in February, but it's embedded far enough into a long post that I don't remember reading down that far. The behavior is specific to a hub-and-spoke RWDC-->RODC scenario, in a case where account lockouts are configured and a user in the branch incurs an account lockout during or near to a WAN outage.

Scenario 1: AD domain is configured with a timed account lockout, such that the account automatically unlocks after, let's say 10 minutes. Branch office with RODC incurs a WAN outage, and a user whose password is stored locally on the RODC tries to log on. Locks out her account as expected, since lockoutTime and badPasswordTime (is that the right attribte? Close to that) gets written locally. WAN remains offline for longer than the duraton of the lockout time, 10 minutes in our example. 10 minutes elapse, give or take a nanosecond, and the account unlocks as expected.

So far, so good.

Here's the 2 scenarios that I don't necessarily like so much:

Scenario 2: AD domain is configured with a timed account lockout, such that the account automatically unlocks after, let's say 10 minutes. Branch office with RODC incurs a WAN outage, and a user whose password is stored locally on the RODC tries to log on. Locks out her account as expected, just like before. But in this case, the WAN only remains offline for a small amount of time, even a few seconds. As soon as the WAN comes back online? The user who has been locked out locally on the RODC? Has his/her lockoutTime immediately overwritten with a value of 0, and the account is immediately unlocked.

Scenario 3 is very similar: AD domain is configured with a hard account lockout, such that administrator/help desk need to manually unlock the account before it can be used again. Again, WAN goes offline, user locks out their account on the RODC, WAN comes back up, lockoutTime is immediately reset to 0 and the account is unlocked.

...the frack? ...the fracking frack? I mean, I recognize that the actual attack vector that this enables is minimal, but I'm still not keen on AD overriding my explicitly-defined wishes just because a WAN link flapped for a few seconds.

(Open item: what actual mechanism is causing this to happen? I think I'm seeing Ned Pyle later this week who was the originator of the blog post in question, so we'll see what light he can shed.)

Update on Wednesday, July 23, 2008 at 02:19PM by Laura E. Hunter

Unfortunately, Ned's assessment is that the automatic unlocking-ness happens "by magick."  I'm sure it was done as an intentional design decision somewhere down the line, as it doesn't strike me as something that would be happening by accident.  And I'm just not loving the notion of a flapping WAN link having the ability to override configuration decisions that I have intentionally put in place for my domain.