raktimb Absent Member.
Absent Member.
285 views

AD attribute lockoutTime synchronization in Publisher channe


Hi All,

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?

321


+----------------------------------------------------------------------+
|Filename: DriverPackageDetails.JPG |
|Download: https://forums.netiq.com/attachment.php?attachmentid=321 |
+----------------------------------------------------------------------+

--
Thanks,
Raktim Banerjee
Enterprise Risk and Security Services (ERSS)
------------------------------------------------------------------------
raktimb's Profile: https://forums.netiq.com/member.php?userid=4402
View this thread: https://forums.netiq.com/showthread.php?t=53972

Labels (1)
0 Likes
1 Reply
Knowledge Partner
Knowledge Partner

Re: AD attribute lockoutTime synchronization in Publisher channe


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.


MSDN http://tinyurl.com/q37c584 recommend to use Lockout-Duration

> 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".

Alex


--
al_b
------------------------------------------------------------------------
al_b's Profile: https://forums.netiq.com/member.php?userid=209
View this thread: https://forums.netiq.com/showthread.php?t=53972

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.