Knowledge Partner
Knowledge Partner
259 views

Password change in AD slow...

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

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.


Labels (1)
0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Password change in AD slow...

Geoffrey Carman wrote:

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


My understanding was that the prior password is only valid for 1 hour (default, but configurable) to prevent lockouts. The new password works straight away. (at least that was my understanding)
There might be some throttling in AD to stop you hammering the server with auth requests. Or just an AD bug.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Password change in AD slow...

On 5/5/2015 4:43 PM, Alex McHugh wrote:
> Geoffrey Carman wrote:
>
>> 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.

>
> My understanding was that the prior password is only valid for 1 hour (default, but configurable) to prevent lockouts. The new password works straight away. (at least that was my understanding)
> There might be some throttling in AD to stop you hammering the server with auth requests. Or just an AD bug.


So old password is valid for 1 hour. I thought it was just not flagged
as an intruder lockout event for the last password. Interesting.

So then from a Validator perspective, saying Assert Password Not Equals
in AD, is a bad test. But why does that change in 2-3 minutes. Hmm...

Since I am trying to lock out access, it is important that I actually
lock access on this account. (wonder if I need to do two or three
random changes to succeed?)

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password change in AD slow...

Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
> On 5/5/2015 4:43 PM, Alex McHugh wrote:
>> Geoffrey Carman wrote:
>>
>>> 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.

>>
>> My understanding was that the prior password is only valid for 1 hour
>> (default, but configurable) to prevent lockouts. The new password works
>> straight away. (at least that was my understanding)
>> There might be some throttling in AD to stop you hammering the server
>> with auth requests. Or just an AD bug.

>
> So old password is valid for 1 hour. I thought it was just not flagged
> as an intruder lockout event for the last password. Interesting.


Yes, password history needs to be on as well I believe.

https://support.microsoft.com/en-us/kb/906305/

You can turn it off.

> So then from a Validator perspective, saying Assert Password Not Equals
> in AD, is a bad test. But why does that change in 2-3 minutes. Hmm...
>
> Since I am trying to lock out access, it is important that I actually
> lock access on this account. (wonder if I need to do two or three random
> changes to succeed?)


Yes. It seems clear that only the last password prior to change is
affected. So change it twice and then re-auth multiple times with the
original password to lock.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...
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.