kkrasmussen Absent Member.
Absent Member.
898 views

Reset/remove intrution detection


Hi board.

I am working on an AD driver in IDM 4.0.1.
We have account tracking enabled.

Because we are using multi affiliation accounts in eDirectory we have
some complexity of why and how we have designed this solution.
What is a side effect though is that when we needs to administrate to
core information or lifecycle management, we are executing the
modifications on the main User object, and then letting a lopbackdriver
do the synchronisation to the other attached user objects.

Because of the multi affiliation design we are building workflows for
administration the objects, including actions like: Enabling, disabling,
password change and locked out/intrution detection.

So we needs to be able to reset lockoutTime in AD to 0 - without being
hit by the account tracking and re-writing of values based on the later
queries.

*What we want to acheive:*
When a user is locked out in AD we will set the *Locked By Intruder*
attr. to TRUE, *Login Intruder Attempts* equal the number of allowed
login attempts due to directory policies, *Login Intruder Address* equal
{netAddrType="0", netAddr=""} and delete/clear *Login Intruder Reset
Time*.
This part we have tested and verified successfully to be possible.

We have developed a WF that deletes/clears those attributes again, and
when *Locked By Intruder* is cleared or changing from TRUE, set
lockoutTime in AD to zero.

*Our issue*
When we are doing this (setting the lockoutTime to zero) we are hit
by/challenged by the Format Conversion policy that is part of a Novell
Package (NOVLADDCFG-otp-FormatConversions and
NOVLADDCFG-itp-FormatConversions) that formats the zero to a timestamp.
In order to work around this I have tryed building a policy in Command
Transform where I set a local variable drivervise to true, and then in
Output transform i set the dest atrr val lockoutTime to zero if the
variable is equal true. This works. However. When it tracks or reads
status on the object in AD, the lockoutTime is returned NOT as zero and
is therefore triggered by the rule we ALSO had to build in Input
transform in order to listen on the lockoutTime and determine if it is
anything else than zero. Therefore it handles the event as if it was
indeed a lockout and NOT a reset of lockout.

I would like to have the described functionality without breaking
standard functionality in driver, so I has to ask if anyone has a
solution for this?


--
kkrasmussen
------------------------------------------------------------------------
kkrasmussen's Profile: http://forums.novell.com/member.php?userid=20966
View this thread: http://forums.novell.com/showthread.php?t=450312

Labels (1)
0 Likes
7 Replies
kkrasmussen Absent Member.
Absent Member.

Re: Reset/remove intrution detection


What is the idea behind the standard AD driver functionality (as
provided by the newest packages ofc) where the lockoutTime is mapped to
Login Intruder Reset Time and then there is no functionalty to actualy
mark an object as Locked By Intruder?
And what is worse is that if I removes the Login Intruder Reset Time,
nothing happens because the nature of AD states that we CANNOT manualy
manipulate the lockoutTime to anything else than zero. Only AD internaly
can assign another value than zero. So out of the box then all this
driver do (with the default packages enabled ofc) is to set the Login
Intruder Reset Time in Publisher channel and that is it.

So if I actually wanna to set the lockoutTime attr to zero in AD in
order to remove the lockout mark AND also to actually mark the users as
locked out in eDir when they are loacket out in AD, how can I acheive
this?

As a second priority, I would also like to synchronize badPwdCount to
Login Intruder Attempts, so that when they try to logon it does not
matter from where they tryes to logon (in AD or eDir), they will still
be locked out due to directory policies (which is the same in AD and
eDir).

I am perfectly aware that the best way to truly insure that the user is
really loacked out, is to either do x number of failed SOAP
authentications or LDAP binds. Tests of this approach (LDAP binds
through an ecmascript - XPATH in the driver) has been successfully
against eDir but seems to be alot more dificult against AD, despite the
fact that I am successfully connected to the AD with an LDAP browser
(Apache Directory Studio). It simply receives a timeout no matter what I
do (has even hard-coded all the parameters to connect AND BIND directly
in the script) it still times out.
But this is not a must have feature at this point. The most important
thing to accomplish for me, is this use case:
A user is locked out from AD due to to many failed logins. The
associated user object in eDir is marked as locked out aswell.
The user is contacting his manager and states that he can no longer
login.
The manager starts a WF and browses to the user only to find that the
user is intruder locket out.
From the same wf, the manager chooses to reset the Locked By Intruder
mark.
The account in AD is now no longer locked by intruder (lockoutTime is
set to zero).

Anyone who can at least point me in the right direction?


--
kkrasmussen
------------------------------------------------------------------------
kkrasmussen's Profile: http://forums.novell.com/member.php?userid=20966
View this thread: http://forums.novell.com/showthread.php?t=450312

0 Likes
TE Super Contributor.
Super Contributor.

Re: Reset/remove intrution detection


The time conversion for lockoutTime in the AD driver, IMHO, should be
removed. AD will only let you set that value to zero, you cannot set
any other value (i.e. you cannot lock an account deliberately). The
problem is the eDir value is a 32 bit time, while the AD value is a 64
bit time. Setting the eDir attribute to zero causes a non-zero value to
be sent to AD when it gets converted. I'd have to go back thru my old
projects, but I believe all I did was disable the lockoutTime conversion
rule, and set the AD attribute, by Destination Name, to zero whenever
anybody cleared an intruder lockout in eDir. AD has no attribute that
says Account Locked, other than a non-zero value in lockoutTime.

When you try to carry intruder lockouts down to AD, there is java code
you can use to do 5 sequential logins (or however many will lock an
account) with a known bad password (one huge string usually works). With
4.0.1, I believe there are libraries now available that make the code
readily available in a rule.


--
tse7147
------------------------------------------------------------------------
tse7147's Profile: http://forums.novell.com/member.php?userid=4730
View this thread: http://forums.novell.com/showthread.php?t=450312

0 Likes
kkrasmussen Absent Member.
Absent Member.

Re: Reset/remove intrution detection


I am aware of all that. But about to totaly remove the Login Intruder
Reset Time attribute from the filter and to remove/disable the format
conversion rules, that is something I can work with.
The LDAP failed binds approach is another thing. I have tryed this but
it cant even connect - even though I am already connected with an
external LDAP browser (apache Directory Studio) - and I have tested the
same code against eDir with great success.

It is NOT important for me to synchronize lockout FROM eDir TO AD
(eDIr->AD). First priority is to be able to syncronize the lockout FROM
AD TO eDir (edir<-AD) and THEN remove intrution detection via a WF in
eDir and synchronize THAT to AD (eDir->AD).

Like this:

AD DRIVER PUB (AD->):
lockoutTime changes FROM 0
And/Or lockoutTime NOT equal 0:
----------------------------------------------
Set Locked By Intruder equal TRUE (in eDir).
Set Login Intruder Attempts equal 5 (in eDir).
Set Login Intruder Address equal '0# ' (in eDir).

WORK FLOW IN UA:
Mark the User object for "remove Locked By Intruder checkmark".
------------------------------------------------------------------
Flow data: Set Locked By Intruder equal FALSE (in eDir).
Flow data: Delete Attribute Login Intruder Attempts (in eDir).
Flow data: Delete Attribute Login Intruder Address (in eDir).

AD DRIVER SUB (EDIR->AD):
Locked By Intruder ghanges from TRUE
and/or Locked By Intruder NOT equal TRUE.
----------------------------------------------------
Set lockoutTime equal 0 (zero).

This is what is my first priority.


--
kkrasmussen
------------------------------------------------------------------------
kkrasmussen's Profile: http://forums.novell.com/member.php?userid=20966
View this thread: http://forums.novell.com/showthread.php?t=450312

0 Likes
lgreco Absent Member.
Absent Member.

Re: Reset/remove intrution detection


Hi, i solved that problem doing an evaluation of the attribute "Login
Intruder Reset Time" on CTP to the value that time convert on ITP
ejected. Like this:

if operation attribute 'Login Intruder Reset Time' not equal
"4294967295" ---> this means that lockoutTime on AD changes from 0
(zero) to other value (4294967295 is my zero after ITP)
Then lock account on eDir

To detect unlock account on AD i also evaluate the value "4294967295",
means that lockoutTime is equal to 0 (zero) and i have to unlockaccount
on eDir

This is how i solve the sinc AD --> eDir

in the other hand, you can only Unlock accounts on AD, but for this
task the attribute dirxml-uACLockout works fine. Have to map it to
"Locked By Intruder" and set the filter to sync only in Suscriber
channel.

The attribute "Login Intruder Reset Time" is mapped to lockoutTime and
set on the filter to sync only in the Publisher Channel.


I hope this information helps and sorry my English !


PD: I take the post to ask if solved the problematic that lockoutTime
sends the current time and not the offset of 30 minutes for example ?



kkrasmussen;2165999 Wrote:
> I am aware of all that. But about to totaly remove the Login Intruder
> Reset Time attribute from the filter and to remove/disable the format
> conversion rules, that is something I can work with.
> The LDAP failed binds approach is another thing. I have tryed this but
> it cant even connect - even though I am already connected with an
> external LDAP browser (apache Directory Studio) - and I have tested the
> same code against eDir with great success.
>
> It is NOT important for me to synchronize lockout FROM eDir TO AD
> (eDIr->AD). First priority is to be able to syncronize the lockout FROM
> AD TO eDir (edir<-AD) and THEN remove intrution detection via a WF in
> eDir and synchronize THAT to AD (eDir->AD).
>
> Like this:
>
> AD DRIVER PUB (AD->):
> lockoutTime changes FROM 0
> And/Or lockoutTime NOT equal 0:
> ----------------------------------------------
> Set Locked By Intruder equal TRUE (in eDir).
> Set Login Intruder Attempts equal 5 (in eDir).
> Set Login Intruder Address equal '0# ' (in eDir).
>
> WORK FLOW IN UA:
> Mark the User object for "remove Locked By Intruder checkmark".
> ------------------------------------------------------------------
> Flow data: Set Locked By Intruder equal FALSE (in eDir).
> Flow data: Delete Attribute Login Intruder Attempts (in eDir).
> Flow data: Delete Attribute Login Intruder Address (in eDir).
>
> AD DRIVER SUB (EDIR->AD):
> Locked By Intruder ghanges from TRUE
> and/or Locked By Intruder NOT equal TRUE.
> ----------------------------------------------------
> Set lockoutTime equal 0 (zero).
>
> This is what is my first priority.



--
lgreco
------------------------------------------------------------------------
lgreco's Profile: http://forums.novell.com/member.php?userid=123587
View this thread: http://forums.novell.com/showthread.php?t=450312

0 Likes
Knowledge Partner
Knowledge Partner

Re: Reset/remove intrution detection

On Fri, 06 Jan 2012 07:26:01 +0000, kkrasmussen wrote:

> What is the idea behind the standard AD driver functionality (as
> provided by the newest packages ofc) where the lockoutTime is mapped to
> Login Intruder Reset Time and then there is no functionalty to actualy
> mark an object as Locked By Intruder?


Could be an oversight, I guess. Or maybe it's deliberate, though I'm as
confused as you are as to why they'd do that. I guess, conceptually, that
lockoutTime is analogous to Login Intruder Reset Time, so mapping those
makes some sense. But yeah, I'd agree that this doesn't provide all of
the functionality that you might initially think.


> And what is worse is that if I
> removes the Login Intruder Reset Time, nothing happens because the
> nature of AD states that we CANNOT manualy manipulate the lockoutTime to
> anything else than zero. Only AD internaly can assign another value than
> zero. So out of the box then all this driver do (with the default
> packages enabled ofc) is to set the Login Intruder Reset Time in
> Publisher channel and that is it.
>
> So if I actually wanna to set the lockoutTime attr to zero in AD in
> order to remove the lockout mark AND also to actually mark the users as
> locked out in eDir when they are loacket out in AD, how can I acheive
> this?


Publisher channel:

- if op-attr lockoutTime is being removed, then remove destination
attributes Locked By Intruder / Login Intruder Address / Login Intruder
Attempts.

- if op-attr lockoutTime is being added, set destination attributes
Locked By Intruder = True / Login Intruder Address (?) / Login Intruder
Attempts (== whatever your lockout attempts policy is).

Subscriber channel:

- if op-attr Locked By Intruder changing to true, there's a Javascript
you can use to bang on the associated AD object to cause it to lockout. I
think it's in Cool Solutions.

- if op-attr Locked By Intruder changing to false, set destination
attribute lockoutTime = 0.

That should work, I think.


> As a second priority, I would also like to synchronize badPwdCount to
> Login Intruder Attempts, so that when they try to logon it does not
> matter from where they tryes to logon (in AD or eDir), they will still
> be locked out due to directory policies (which is the same in AD and
> eDir).


That should work, I think. You would need to then also compare Login
Intruder Attempts on the User object to the parent container's Login
Intruder Limit, and if Login Intruder Attempts >= Login Intruder Limit,
then set Locked By Intruder / Login Intruder Address / Login Intruder
Reset Time and Login Intruder Attempts.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.novell.com

Please post questions in the forums. No support provided via email.

0 Likes
Knowledge Partner
Knowledge Partner

Re: Reset/remove intrution detection

>> What is the idea behind the standard AD driver functionality (as
>> provided by the newest packages ofc) where the lockoutTime is mapped to
>> Login Intruder Reset Time and then there is no functionalty to actualy
>> mark an object as Locked By Intruder?

>
> Could be an oversight, I guess. Or maybe it's deliberate, though I'm as
> confused as you are as to why they'd do that. I guess, conceptually, that


Thats the thing. We do not know what the intent was. Alas, I think
this example is an oversight.


> - if op-attr Locked By Intruder changing to true, there's a Javascript
> you can use to bang on the associated AD object to cause it to lockout. I
> think it's in Cool Solutions.


If you happen to find this article, I would be interested in a link,
since I do not know of such a thing.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Reset/remove intrution detection

On Mon, 09 Jan 2012 16:32:48 +0000, Geoffrey Carman wrote:

>>> What is the idea behind the standard AD driver functionality (as
>>> provided by the newest packages ofc) where the lockoutTime is mapped
>>> to Login Intruder Reset Time and then there is no functionalty to
>>> actualy mark an object as Locked By Intruder?

>>
>> Could be an oversight, I guess. Or maybe it's deliberate, though I'm as
>> confused as you are as to why they'd do that. I guess, conceptually,
>> that

>
> Thats the thing. We do not know what the intent was. Alas, I think
> this example is an oversight.


I agree, but without knowing the author's intent, there's still a
(slight) possibility that it's deliberate. IMHO, it's a bug, but let's
see what Aaron has to say about it.


>> - if op-attr Locked By Intruder changing to true, there's a Javascript
>> you can use to bang on the associated AD object to cause it to lockout.
>> I think it's in Cool Solutions.

>
> If you happen to find this article, I would be interested in a link,
> since I do not know of such a thing.


Hm. Well, I thought I remembered reading a CS article, but I can't find
it now. The closest I can find seems to be this forum thread:

http://forums.novell.com/forums/netiq/netiq-product-discussion-forums/
identity-manager/im-engine-drivers/355417-edirectory-ad-intruder-lockout-
discussion-again.html



--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.novell.com

Please post questions in the forums. No support provided via email.

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.