Knowledge Partner
Knowledge Partner
641 views

Intruder Lockout, unlock, writes 3661 to Login Intruder Reset Time

I have an IDM driver syncing Lockout events from AD to eDir and eDir to
AD. Basically out of the box policies.

So the policies decide that you cleared lockout in eDir to clear it in
AD, by seeing a time value set to 0.

But SSPR seems consistently setting it to 3661. Which is 1 hour, 1
minute, and 1 second into Jan 1, 1970 in CTIME? (Is this some sort of
bizarre Rememberance Day joke? 11th hour or 11th month, etc? if so,
classy! If not, meh)

Why? Why 3661? Is this always going to be the case?

(As in, I can easily modify the policy to treat 3661 as 0, or actually
any value less than NOW in CTIME, but all that is meaningless if there
is a reason and it changes without my understanding why).

Here is an example of the event it sent:

[06/12/15 13:37:50.307]:AD ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.0.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify cached-time="20150612173750.074Z" class-name="User"
src-dn="\ACME\Acme\Data\Users\A1234">
<association
state="associated">3159dae838a73a47a97263812d477842</association>
<modify-attr attr-name="lockoutTime">
<remove-value>
<value timestamp="1434130261#13" type="time">1434132061</value>
</remove-value>
<add-value>
<value timestamp="1434130665#14" type="time">3661</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>


User IS unlocked, but the way the IDM driver works, it maps the Login
Intruder Reset Time to intruderLockout in AD, which are both time based.
So SSPR is clearly resetting the Locked By Intruder attr (good!) but
setting 3661 in this attr is odd.
0 Likes
2 Replies
Knowledge Partner
Knowledge Partner

Re: Intruder Lockout, unlock, writes 3661 to Login Intruder ResetTime

Silly theory:

The developer of this product is non-dumb, but I could see somebody trying
to set something to the beginning of 1970 and forgetting the 12:00 a.m.
(aka 00:00:00) is actually part of this day. They might then try 01:00,
which gets 3600 seconds into the year. Trying to avoid problems for other
dumb applications (this may be the reason for everything) maybe they
decided to just put it out one minute and one second, so now you have 61
seconds, but because of the first error (or correction) it's 3661. Since
in other time formats this would just be 1970-01-01 01;01:01, it seems
less-weird, and maybe less-distant, depending on how you look at it.

Since SSPR is made to work with software that may be questionable in
quality, I can imagine all of this being done on purpose to avoid confusion.

Just a random thought. Good observation, by the way.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Knowledge Partner
Knowledge Partner

Re: Intruder Lockout, unlock, writes 3661 to Login Intruder ResetTime

On 6/12/2015 1:53 PM, ab wrote:
> Silly theory:
>
> The developer of this product is non-dumb, but I could see somebody trying


I would never describe Jason that way. 🙂

> to set something to the beginning of 1970 and forgetting the 12:00 a.m.
> (aka 00:00:00) is actually part of this day. They might then try 01:00,
> which gets 3600 seconds into the year. Trying to avoid problems for other
> dumb applications (this may be the reason for everything) maybe they
> decided to just put it out one minute and one second, so now you have 61
> seconds, but because of the first error (or correction) it's 3661. Since
> in other time formats this would just be 1970-01-01 01;01:01, it seems
> less-weird, and maybe less-distant, depending on how you look at it.


When you write it out that way, 1970-01-01 01:01:01 it looks pretty
cool. To heck with your Jason is not dumb theory. I think 3661 makes
sense since that date string looks so cool. 🙂

> Since SSPR is made to work with software that may be questionable in
> quality, I can imagine all of this being done on purpose to avoid confusion.


So I changed the AD driver policy to see if the added value is less than
the current time, (i.e. is in the past) and thus resets it in AD. Since
if it is in the past, all is good regardless of what crazy date in the
past it happens to be set too.

Now we should find a use case where he needs a second special value and
suggest 93722 so that we get a date of Jan 2, 1970, 02:02:02

Hehe. Can have a lot of fun with this stuff.


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.