sma2006 Outstanding Contributor.
Outstanding Contributor.
343 views

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
Labels (1)
0 Likes
7 Replies
sma2006 Outstanding Contributor.
Outstanding Contributor.

Re: Continuous activity on AD driver - cannot see the reason

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 ?
0 Likes
Knowledge Partner
Knowledge Partner

Re: Continuous activity on AD driver - cannot see the reason

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Continuous activity on AD driver - cannot see the reason

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


0 Likes
Knowledge Partner
Knowledge Partner

Re: Continuous activity on AD driver - cannot see the reason

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Continuous activity on AD driver - cannot see the reason

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.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
sma2006 Outstanding Contributor.
Outstanding Contributor.

Re: Continuous activity on AD driver - cannot see the reason

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Continuous activity on AD driver - cannot see the reason

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.)
______________________________________________
https://www.is4it.de/identity-access-management
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.