remove-association not always working

IDM 4.5.2 (will try and test with 4.5.3 shortly)

This is a pretty standard sub-ctp entitlement policy.

Entitlement revoked, associated
command transform cleanup/revoke association as determined by gcv

Expected result, remove association and veto original event.
Actual result, every *second* time I test, the association is not
removed even though the trace says success.


[06/10/16 11:32:22.464]:acme ST:Applying policy:
% CCsub-ctp-EntitlementsImpl%-C.
[06/10/16 11:32:22.464]:acme ST: Applying to modify #1.
[06/10/16 11:32:22.464]:acme ST: Evaluating selection criteria for
rule 'UserAccount Entitlement change (Delete Option)'.
[06/10/16 11:32:22.465]:acme ST: (if-global-variable
'drv.entitlement.UserAccount' equal "true") = TRUE.
[06/10/16 11:32:22.465]:acme ST: (if-global-variable
'drv.entitlement.remove' equal "delete") = FALSE.
[06/10/16 11:32:22.465]:acme ST: Rule rejected.
[06/10/16 11:32:22.465]:acme ST: Evaluating selection criteria for
rule 'UserAccount Entitlement change (Disable Option)'.
[06/10/16 11:32:22.465]:acme ST: (if-global-variable
'drv.entitlement.UserAccount' equal "true") = TRUE.
[06/10/16 11:32:22.465]:acme ST: (if-global-variable
'drv.entitlement.remove' equal "disable") = TRUE.
[06/10/16 11:32:22.465]:acme ST: (if-class-name equal "User") =
TRUE.
[06/10/16 11:32:22.465]:acme ST: (if-operation match "add|modify")
= TRUE.
[06/10/16 11:32:22.465]:acme ST: (if-entitlement 'UserAccount'
changing) = TRUE.
[06/10/16 11:32:22.466]:acme ST: Rule selected.
[06/10/16 11:32:22.466]:acme ST: Applying rule 'UserAccount
Entitlement change (Disable Option)'.
[06/10/16 11:32:22.466]:acme ST: Action:
do-for-each(arg-node-set(token-removed-entitlement("UserAccount"))).
[06/10/16 11:32:22.466]:acme ST:
arg-node-set(token-removed-entitlement("UserAccount"))
[06/10/16 11:32:22.466]:acme ST:
token-removed-entitlement("UserAccount")
[06/10/16 11:32:22.466]:acme ST: Token Value:
{<entitlement-impl> @id = "" @name = "UserAccount" @qualified-src-dn =
"O=acme\OU=people\OU=employees\CN=user1" @src = "UA" @src-dn =
"\acme-TREE\acme\Pers
oner\employees\user1" @src-entry-id = "12345" @state = "0"}.
[06/10/16 11:32:22.466]:acme ST: Arg Value:
{<entitlement-impl> @id = "" @name = "UserAccount" @qualified-src-dn =
"O=acme\OU=people\OU=employees\CN=user1" @src = "UA" @src-dn =
"\acme-TREE\acme\Person
er\employees\user1" @src-entry-id = "12345" @state = "0"}.
[06/10/16 11:32:22.467]:acme ST: Performing actions for
local-variable(current-node) = <entitlement-impl> @id = "" @name =
"UserAccount" @qualified-src-dn =
"O=acme\OU=people\OU=employees\CN=user1" @src = "UA
" @src-dn = "\acme-tree\acme\people\employees\user1" @src-entry-id =
"12345" @state = "0".
[06/10/16 11:32:22.470]:acme ST: Action:
do-remove-association(when="after",arg-association(token-association()))
..
[06/10/16 11:32:22.470]:acme ST:
arg-association(token-association())
[06/10/16 11:32:22.470]:acme ST: token-association()
[06/10/16 11:32:22.470]:acme ST: Token Value:
"{6BEE6FD9-9298-c146-1DB4-6BEE6FD99298}".
[06/10/16 11:32:22.471]:acme ST: Arg Value:
"{6BEE6FD9-9298-c146-1DB4-6BEE6FD99298}".
[06/10/16 11:32:22.471]:acme ST: Action: do-veto().
[06/10/16 11:32:22.488]:acme ST: Direct command from policy
[06/10/16 11:32:22.488]:acme ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.2.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<remove-association
event-id="sr-ped-idm-01#20160610093222#1#1:3213196f-1296-4daa-fbb0-6f191
3329612">{6BEE6FD9-9298-c146-1DB4-6BEE6FD99298}<operation-data>
<entitlement-impl id="" name="UserAccount"
qualified-src-dn="O=acme\OU=people\OU=employees\CN=user1" src="UA"
src-dn="\acme-tree\acme\people\employees\user1" src-entry-id="12345"
state="0">{"ID":"acme-tree"}</en
titlement-impl>
</operation-data>
</remove-association>
</input>
</nds>
[06/10/16 11:32:22.489]:acme ST: Pumping XDS to eDirectory.
[06/10/16 11:32:22.489]:acme ST: Performing operation
remove-association for .
[06/10/16 11:32:22.500]:acme ST: Processing returned document.
[06/10/16 11:32:22.500]:acme ST: Processing operation <status> for .
[06/10/16 11:32:22.500]:acme ST:
DirXML Log Event -------------------
Driver: \acme-TREE\acme\ICT\DirXML\Driver Set\acme
Channel: Subscriber
Object: \acme-tree\acme\people\employees\user1
Status: Success
[06/10/16 11:32:22.511]:acme ST: Direct command from policy result
[06/10/16 11:32:22.511]:acme ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.2.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status
event-id="sr-ped-idm-01#20160610093222#1#1:3213196f-1296-4daa-fbb0-6f191
3329612" level="success"><operation-data>
<entitlement-impl id="" name="UserAccount"
qualified-src-dn="O=acme\OU=people\OU=employees\CN=user1" src="UA"
src-dn="\acme-tree\acme\people\employees\user1" src-entry-id="12345"
state="0">{"ID":"acme-tree"}</en
titlement-impl>
</operation-data>
<application>DirXML</application>
<module>acme</module>
<object-dn>\acme-tree\acme\people\employees\user1</object-dn>
<component>Subscriber</component>
</status>
</output>
</nds>
[06/10/16 11:32:22.512]:acme ST:Policy returned:
[06/10/16 11:32:22.512]:acme ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.2.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input/>
</nds>



  • That is truly strange.

    I have never seen it not work when the engine reports a success back.
    Patching is what comes to my mind as well. Both IDM and eDir if needed.
    It could very well be more related to eDir.

    Could it be that it actually does remove the association on the replica
    you run on but you have some problem with the replication?

    Does when="after" in > do-remove-association(when="after",arg-association(token-association()))" make a difference i you for example change it to direct?

    Just a few thoughts that pop up, you might have tried them already.


    --
    joakim_ganse
    ------------------------------------------------------------------------
    joakim_ganse's Profile: https://forums.netiq.com/member.php?userid=159
    View this thread: https://forums.netiq.com/showthread.php?t=56012

  • joakim ganse wrote:

    >
    > That is truly strange.
    >
    > I have never seen it not work when the engine reports a success back.
    > Patching is what comes to my mind as well. Both IDM and eDir if
    > needed. It could very well be more related to eDir.


    eDirectory 8.8 SP8 Patch 6 - so not very out of date

    > Could it be that it actually does remove the association on the
    > replica you run on but you have some problem with the replication?
    >


    Single server dev tree

    > Does when="after" in >
    > do-remove-association(when="after",arg-association(token-association()
    > ))" make a difference i you for example change it to direct?
    >
    > Just a few thoughts that pop up, you might have tried them already.


    makes no difference.
  • How are you seeing it is removed? I've traced many red herring because of
    "helpful" caching in Apache Directory Studio, and that is something I've
    seen in various tools that browse directories or similar. Perhaps you are
    being bit by caching. Doesn't seem super-likely considering you said
    "every second time", which implies you have that tracked down pretty closely.

    Only other thought is to dive into ndstrace with options that show too
    much, or maybe setup a driver config that just watches DirXML-Associations
    and see if it sees changes happening, and from where. Auditing could do
    this too, of course.


    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • I have issue of "similar" inconsistency, but it was related to "move" operation in multi-server tree.

    in your situation (single server tree) I only can think about something related to eDir caching technology: you got "successful" feedback about this operation, but results of operation can be just in memory cache and didn't "flushed" to eDir yet.
    Potentially LDAP daemon (especially during "complex" query) can look for "outdated" info on disk.

    This is just my guess.

    Alex
  • ab <ab@no-mx.forums.microfocus.com> wrote:
    > How are you seeing it is removed? I've traced many red herring because of
    > "helpful" caching in Apache Directory Studio, and that is something I've
    > seen in various tools that browse directories or similar. Perhaps you are
    > being bit by caching. Doesn't seem super-likely considering you said
    > "every second time", which implies you have that tracked down pretty closely.
    >


    I haven't ruled out the LDAP tool yet.
    Was mostly using Apache DS. Disconnected from LDAP server and reconnected
    then loaded same DN. Assumed that this would be good enough! Need to test
    more.


    > Only other thought is to dive into ndstrace with options that show too
    > much, or maybe setup a driver config that just watches DirXML-Associations
    > and see if it sees changes happening, and from where. Auditing could do
    > this too, of course.
    >


    Good idea



    --
    If you find this post helpful and are logged into the web interface, show
    your appreciation and click on the star below...
  • On Fri, 10 Jun 2016 19:14:01 0000, Alex Mchugh wrote:

    > ab <ab@no-mx.forums.microfocus.com> wrote:
    >> How are you seeing it is removed? I've traced many red herring because
    >> of "helpful" caching in Apache Directory Studio, and that is something
    >> I've seen in various tools that browse directories or similar. Perhaps
    >> you are being bit by caching. Doesn't seem super-likely considering
    >> you said "every second time", which implies you have that tracked down
    >> pretty closely.
    >>
    >>

    > I haven't ruled out the LDAP tool yet. Was mostly using Apache DS.


    Use iMonitor and see what's there.


    --
    David Gersic
    Knowledge Partner http://forums.microfocus.com
    If you find this post helpful, please click on the star below.
  • David Gersic wrote:

    > On Fri, 10 Jun 2016 19:14:01 0000, Alex Mchugh wrote:
    >
    > > ab <ab@no-mx.forums.microfocus.com> wrote:
    > >> How are you seeing it is removed? I've traced many red herring

    > because >> of "helpful" caching in Apache Directory Studio, and that
    > is something >> I've seen in various tools that browse directories or
    > similar. Perhaps >> you are being bit by caching. Doesn't seem
    > super-likely considering >> you said "every second time", which
    > implies you have that tracked down >> pretty closely.
    > >>
    > >>

    > > I haven't ruled out the LDAP tool yet. Was mostly using Apache DS.

    >
    > Use iMonitor and see what's there.


    iMonitor shows exactly the same.

    alternating, only every second time the association is removed.

    Now. to mention - in sub-etp, I am using Lothar's code as follows.

    Then if the event was for a revoked entitlement, the association should
    be removed.

    This reminds me of the issue as reported in
    https://forums.novell.com/showthread.php/497275-IDM453-changes-set-operation-association-behavior



    <rule notrace="true">
    <description>Add Association</description>
    <comment name="author" xml:space="preserve">Lothar Haeger</comment>
    <conditions>
    <and>
    <if-association op="not-associated"/>
    </and>
    </conditions>
    <actions>
    <do-set-local-variable name="guid" scope="policy">
    <arg-string>
    <token-src-attr name="GUID"/>
    </arg-string>
    </do-set-local-variable>
    <do-set-op-association>
    <arg-association>
    <token-xpath expression="es:decodeGUID($guid)"/>
    </arg-association>
    </do-set-op-association>
    <do-add-association>
    <arg-association>
    <token-association/>
    </arg-association>
    </do-add-association>
    </actions>
    </rule>
  • Just a follow up.

    What I ended up doing was to adjust the sub-etp policy to not set-operation
    association. Now if the object is not associated, it just sets an
    association directly on the object.

    As long as there is an association present on the object by the time the
    event exits sub-etp it seems like that is enough.

    This made the sub-ctp policy work reliably.

    I do suspect some changes have been made related to the association
    processor. Maybe as a result of the lite-association format added in 4.5.
    Don't recall this as a problem before.

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