Continuous activity on AD driver - cannot see the reason

hello,

I have a strange behavior with an AD driver , there is continuous activity on the publisher channel on 2 attributes that I cannot explain.

The driver is running on Windows 2016 server with LDAPS connexion to the DC.

There is no transaction in the cache of the other drivers.

The 2 attributes are set to be reset on the publisher channel , and it looks like there is a kind of loop, but nothing is modified in the ADIR domain.

I really don't know how to troubleshoot this, does anyone knows a way to see if there is anything in the ADIR cache on the DC side ?

thanks


Sylvain
  • Looks like changing the filter attributes to "ignore" instead of "reset" stop the activity .

    So, maybe it's working like that :
    1) A change is made in ADIR to an attribute (publisher)
    2) The attribute is reset from the filter to ADIR (subscriber)
    3) The reset is seen as a change an send back to EDIR (publisher)
    4) The attribute is reset from the filter to ADIR (subscriber)
    5) etc... never ending

    I thought that change from a driver was never read back by the same driver.

    Am I wrong ?
  • On 05/08/2018 05:36 AM, sma wrote:
    >
    > Looks like changing the filter attributes to "ignore" instead of "reset"
    > stop the activity .
    >
    > So, maybe it's working like that :
    > 1) A change is made in ADIR to an attribute (publisher)
    > 2) The attribute is reset from the filter to ADIR (subscriber)
    > 3) The reset is seen as a change an send back to EDIR (publisher)
    > 4) The attribute is reset from the filter to ADIR (subscriber)
    > 5) etc... never ending
    >
    > I thought that change from a driver was never read back by the same
    > driver.


    Yes; a change from a driver can be picked up by the driver if the
    application sends it back as a change. A change from the engine is, by
    default, not picked up by the same part of the engine (the driver config
    object) to avoid engine-side loopback, but application-side loopback is
    possible, even desirable sometimes, based on the application entirely.

    With that written, looping should not usually happen, so we would need to
    see a level three (3) trace to understand the looping and possibly
    understand why it is happening. If MAD is silly enough to see a
    non-change (setting the same value over and over) as a change, then that
    may be something to send to microsoft to fix.

    --
    Good luck.

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

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • On 5/8/2018 7:36 AM, sma wrote:
    >
    > Looks like changing the filter attributes to "ignore" instead of "reset"
    > stop the activity .
    >
    > So, maybe it's working like that :
    > 1) A change is made in ADIR to an attribute (publisher)
    > 2) The attribute is reset from the filter to ADIR (subscriber)
    > 3) The reset is seen as a change an send back to EDIR (publisher)


    I think this is the one here. The change in AD, as the filter resets
    the value, also generates a publisher event to send to eDir. What is
    supposed to happen, is IDM is to look at IDV and see that the value is
    the same (What AD was reset to, the IDV value) and then tamp it out with
    an "Optimize modify determined operation is not required" or somesuch
    message.

    So that is a thought. Is optimize modify turned off? If so, with Reset,
    I think you are asking for a loop.


    > 4) The attribute is reset from the filter to ADIR (subscriber)
    > 5) etc... never ending
    >
    > I thought that change from a driver was never read back by the same
    > driver.
    >
    > Am I wrong ?
    >
    >


  • On 05/08/2018 06:41 AM, Geoffrey Carman wrote:
    >
    > So that is a thought. Is optimize modify turned off? If so, with Reset, I
    > think you are asking for a loop.


    I think optimize modify only applies when a write happens to the engine,
    which would not seem to be the case with an attribute set to reset on the
    Publisher channel.

    --
    Good luck.

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

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • ab wrote:

    > I think optimize modify only applies when a write happens to the engine,
    > which would not seem to be the case with an attribute set to reset on the
    > Publisher channel.


    Yes, that's why it's called "Publisher Optimize Modify" in full and it only
    applies to modifies that pass through the publisher command transforms, i.e.
    direct writes to IDV will not get optimized, regardless of which channel/policy
    they come from.
    Subscriber optimize modify can be implemented in (output) policy but requires
    knowledge of the application schema to be done correctly, i.e. syntax, matching
    rules and single/multi-valued-ness. Here's a simple version that only works
    properly for case-ignore string attributes where IDV and app are both single or
    multi-valued.

    <rule>
    <description>Optimize Modifies</description>
    <comment name="author" xml:space="preserve">Lothar Haeger</comment>
    <conditions>
    <and>
    <if-class-name mode="nocase" op="equal">user</if-class-name>
    <if-association op="associated"/>
    </and>
    </conditions>
    <actions>
    <do-set-local-variable name="optimize-attrs" scope="policy">
    <arg-node-set>
    <token-split delimiter=",">
    <token-text xml:space="preserve">extensionAttribute15</token-text>
    </token-split>
    </arg-node-set>
    </do-set-local-variable>
    <do-for-each>
    <arg-node-set>
    <token-xpath expression="modify-attr[@attr-name=$optimize-attrs]"/>
    </arg-node-set>
    <arg-actions>
    <do-set-local-variable name="current-attr" scope="policy">
    <arg-string>
    <token-xpath expression="$current-node/@attr-name"/>
    </arg-string>
    </do-set-local-variable>
    <do-set-local-variable name="app-values" scope="policy">
    <arg-node-set>
    <token-query scope="entry">
    <arg-association>
    <token-association/>
    </arg-association>
    <arg-string>
    <token-text xml:space="preserve">$current-attr$</token-text>
    </arg-string>
    </token-query>
    </arg-node-set>
    </do-set-local-variable>
    <do-if>
    <arg-conditions>
    <and>
    <if-xpath op="true">$current-node/remove-all-values</if-xpath>
    </and>
    </arg-conditions>
    <arg-actions>
    <do-for-each>
    <arg-node-set>
    <token-xpath expression="$app-values//value"/>
    </arg-node-set>
    <arg-actions>
    <do-if>
    <arg-conditions>
    <and>
    <if-op-attr mode="nocase" name="$current-attr$"
    op="not-equal">$current-node$</if-op-attr>
    </and>
    </arg-conditions>
    <arg-actions>
    <do-remove-dest-attr-value name="$current-attr$">
    <arg-value type="string">
    <token-text xml:space="preserve">$current-node$</token-text>
    </arg-value>
    </do-remove-dest-attr-value>
    </arg-actions>
    <arg-actions/>
    </do-if>
    </arg-actions>
    </do-for-each>
    <do-strip-xpath expression="$current-node/remove-all-values"/>
    </arg-actions>
    <arg-actions>
    <do-for-each>
    <arg-node-set>
    <token-xpath expression="$app-values//value"/>
    </arg-node-set>
    <arg-actions>
    <do-set-local-variable name="current-app-value" scope="policy">
    <arg-string>
    <token-text xml:space="preserve">$current-node$</token-text>
    </arg-string>
    </do-set-local-variable>
    <do-for-each>
    <arg-node-set>
    <token-removed-attr name="$current-attr$"/>
    </arg-node-set>
    <arg-actions>
    <do-if>
    <arg-conditions>
    <and>
    <if-xpath
    op="true">java.lang.String:equalsIgnoreCase($current-node,$current-app-value)</i
    f-xpath>
    </and>
    </arg-conditions>
    <arg-actions>
    <do-set-xml-attr expression="$current-node" name="keep-value">
    <arg-string>
    <token-text xml:space="preserve">true</token-text>
    </arg-string>
    </do-set-xml-attr>
    </arg-actions>
    <arg-actions/>
    </do-if>
    </arg-actions>
    </do-for-each>
    </arg-actions>
    </do-for-each>
    <do-strip-xpath
    expression="$current-node/remove-value/value[not(@keep-value)]"/>
    </arg-actions>
    </do-if>
    <do-for-each>
    <arg-node-set>
    <token-xpath expression="$app-values//value"/>
    </arg-node-set>
    <arg-actions>
    <do-set-local-variable name="current-app-value" scope="policy">
    <arg-string>
    <token-text xml:space="preserve">$current-node$</token-text>
    </arg-string>
    </do-set-local-variable>
    <do-for-each>
    <arg-node-set>
    <token-op-attr name="$current-attr$"/>
    </arg-node-set>
    <arg-actions>
    <do-if>
    <arg-conditions>
    <and>
    <if-xpath
    op="true">java.lang.String:equalsIgnoreCase($current-node,$current-app-value)</i
    f-xpath>
    </and>
    </arg-conditions>
    <arg-actions>
    <do-set-xml-attr expression="$current-node" name="strip-value">
    <arg-string>
    <token-text xml:space="preserve">true</token-text>
    </arg-string>
    </do-set-xml-attr>
    </arg-actions>
    <arg-actions/>
    </do-if>
    </arg-actions>
    </do-for-each>
    </arg-actions>
    </do-for-each>
    <do-strip-xpath expression="$current-node/add-value/value[@strip-value]"/>
    </arg-actions>
    </do-for-each>
    </actions>
    </rule>

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • Hello all,

    Thanks a lot for the infos, it's very helpful.

    The faulty attributes are always different between AD and EDIR because there is some transformations in the sub CTP.

    So the "optimize modify" doesn't help, that's why changes in AD generate a infinite loop.

    I changed the filter to "ignore" instead of "reset" and everything stopped immediately.
  • sma wrote:

    > The faulty attributes are always different between AD and EDIR because
    > there is some transformations in the sub CTP.


    Best practice is to do such transformations both ways in output AND input
    policies, not in only on one channel.

    > So the "optimize modify" doesn't help, that's why changes in AD generate
    > a infinite loop.


    If you do it in the last output transform, this should help avoid unnecessary
    writes to AD, regardless of where and how you transform the values. It takes
    what IDM wants to write to AD and strips everything that's aleady there (or has
    already been removed).

    The loop back to the publisher will happen for the every remaining changes
    regardless, but publisher optimize modify should take of that side for you
    already, provided you transform the AD values back to Edir format in an input
    transform.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)