Take the 2-minute tour ×

I have two LDS servers on the same subnet. They replicate well. If I change an attribute, it gets replicated after 15 seconds.

LDS is configured to honor password policies. When a user makes too many wrong password attemps, his account is locked and that user's lockoutTime attribute is set accordingly.

But lockoutTime is not replicated as urgent. In fact, it is not replicated unless there is another change somewhere in the directory. The lockoutTime attribute will be replicated.

Here is an (edited Wireshark) trace. It shows normal replication trafic

No.   Time     Protocol Length Info
  133 16:23:02 DRSUAPI  562    DsGetNCChanges request
  134 16:23:02 DRSUAPI  3042   DsGetNCChanges response
  152 16:23:17 DRSUAPI  562    DsGetNCChanges request
  157 16:23:17 DRSUAPI  242    DsGetNCChanges response
  230 16:24:57 DRSUAPI  562    DsGetNCChanges request
  231 16:24:57 DRSUAPI  2930   DsGetNCChanges response
  246 16:25:12 DRSUAPI  562    DsGetNCChanges request

Right after that, I lock the user (with a FOR loop and ldifde). Nothing happens, until I give up and change the description attribute on the user, then about 15 seconds later I see the replication go through.

 1984 16:31:05 DRSUAPI  562    DsGetNCChanges request
 1985 16:31:05 DRSUAPI  2930   DsGetNCChanges response

The lockoutTime and description is replicated. As stated here, if I set lockoutTime=0, regular replication occurs after 15 seconds !

I have enabled replication diagnostics. Nothing shows up in the instance's logs because there is no replication. When the replication does trigger, I see a bunch of event 1239 for the up-to-date attributes, two 1240 events. One for the attributes lockoutTime and one for description (which I used to trigger replication).

I have enabled change notification between sites, restarted both services, but it did not make any difference. Maybe because the two servers are on the same subnet.

The Active Directory Technical Specification clearly lists lockoutTime as one of the urgent attributes to replicate.

What could be preventing urgent replication of the lockoutTime attribute ?

share|improve this question
Two questions: Why is it important that lockoutTime be replicated urgently? And do you get a different result if you enter a bad password (eg at the logon screen) vs using ldifde? This blog suggests that merely changing those attributes is not replicated "urgently", but a system-initiated lockout is. –  fission Dec 5 '12 at 9:16
Also, the word "urgent" (and a description of its behaviour) appears on pp 268–270 of the Active Directory Technical Specification document you linked. –  fission Dec 5 '12 at 9:26
The results are the same with ldifde (which I use most of the time), ldp and Apache Directory Studio. I would prefer urgent notification, but would settle for normal replication. –  ixe013 Dec 5 '12 at 14:40
I was reading an old version of MS-ADTS. The latest version does mention urgent replication. Will read and update the question. –  ixe013 Dec 5 '12 at 14:41

1 Answer 1

up vote 1 down vote accepted

(Answering my own question with the result of a support call to Microsoft)

It is a bug in AD-LDS (bugcheck ID 354126). It affects Windows Server 2008, I don't know about Server 2012.

The problem is that no notification is sent to the replicas (neither urgent nor normal). When the account lockout is stored in the DB, LDS does not don't update the global notification list. Hence only after scheduled replication kicks in does the replication occurs.

On way around it is to create a scheduled task that calls

repadmin /syncall localhost:389

This call will generate about 42k of network trafic if there is nothing to replicate.

The other way around the problem is to... do nothing. The bug allows an attacker to double his chance at guessing a password. It is hard to exploit because users usually don't call LDS directly. And even if they did, this bug would only double their chances.

share|improve this answer

Your Answer


