I am trying to synchronize lockoutTime from AD to eDirectory. But the AD Driver is not picking the changes. There is no trace of the event in Remote Loader and Driver log.
But I was able to set lockoutTime from subscriber channel. What can be the cause? I am using IDM 4.0.2 Driver. And the base package is: 2.0.0.X Please see the attachment for driver version details. Is this a version issue?
Hi Raktim, What version of Windows you use? I think that Windows 2008 or 2012.
I believe that you got situation with one of "known" bug in AD, that (according to symptoms) was never fixed
Unofficial answer provided to similar question in 2013: > > (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. >
> 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.
> This attribute value is only reset when the account is logged onto > successfully. This means that this value may be non zero, yet the > account is not locked out. *To accurately* determine if the account is > locked out, you must add the *Lockout-Duration* to this time and compare > the result to the current time, accounting for local time zones and > daylight savings time.
Really I'm not sure if Lockout-Duration will help you in your case: it can be "constructed" attribute on AD end and will be available "by request".