mjstew Frequent Contributor.
Frequent Contributor.
557 views

Case Sensitivity of "Virtual" Attributes

Hello!

One of our loopback drivers is responsible for writing name parts (first name, surname, display name, etc.) to the user object that's visible to the outside world, which we call the directory object.

A long time ago, a design decision was made in this driver to create "virtual" attributes in the driver filter for the name parts which are changing, such as firstnamechange, surnamechange, etc. This was so that the attributes would be retained when they "rounded the corner" from the subscriber output transform to the publisher input transform (again, this is a loopback driver).

What we're seeing is that, sometimes, a person's name needs to change case in the system of record, however, the case change is not updated in their publically visible directory object.

We are wondering if the issue is related to these virtual attributes. Since they're "virtual", i.e., fake, they have no schema definition. What are your thoughts?

Two other things we're considering:

- If the attributes into which the values received from the system of record are case ignore string, IDM wouldn't pick up the changes, would it?

- Could an if-then which is set to case sensitive be causing the problem? I've looked at a few instances of where these attributes occur and I'm not seeing them being compared in if-then statements.

Many thanks for your help!
Jack Stewart
University of Michigan
Labels (1)
0 Likes
10 Replies
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

mjstew;2483173 wrote:
Hello!

One of our loopback drivers is responsible for writing name parts (first name, surname, display name, etc.) to the user object that's visible to the outside world, which we call the directory object.

A long time ago, a design decision was made in this driver to create "virtual" attributes in the driver filter for the name parts which are changing, such as firstnamechange, surnamechange, etc. This was so that the attributes would be retained when they "rounded the corner" from the subscriber output transform to the publisher input transform (again, this is a loopback driver).

What we're seeing is that, sometimes, a person's name needs to change case in the system of record, however, the case change is not updated in their publically visible directory object.

We are wondering if the issue is related to these virtual attributes. Since they're "virtual", i.e., fake, they have no schema definition. What are your thoughts?

Two other things we're considering:

- If the attributes into which the values received from the system of record are case ignore string, IDM wouldn't pick up the changes, would it?

- Could an if-then which is set to case sensitive be causing the problem? I've looked at a few instances of where these attributes occur and I'm not seeing them being compared in if-then statements.

Many thanks for your help!
Jack Stewart
University of Michigan


Hi Jack, long time no see. If I had to guess, it's most likely that the publisher optimizer is seeing that the attribute to be written is defined with case-ignore-string as the syntax, and the change is only in case, so the optimizer throws it away. That's standard behaviour, though it can be worked around.

IDM will see the change on the subscriber. I don't think your "virtual" attributes come in to play here at all. It's going to be on the publisher side where the optimizer kicks in. A level 3 trace should show that happening.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

dgersic wrote:

> If I had to guess, it's most likely that the
> publisher optimizer is seeing that the attribute to be written is
> defined with case-ignore-string as the syntax, and the change is only in
> case, so the optimizer throws it away. That's standard behaviour, though
> it can be worked around.


Yes, that's most likely what's happening here. To workaround, simply disable
publisher optimize modify in the filter for those attributes.
Optionally (maybe even mandatory, depending on how you generate your virtual
attributes) you can also add your own, case-sensitive optimize modify code as
first publisher command transform (immediately after the engine's
optimization). Here's the core of what I use most:

<rule>
<description>Publisher Optimize Modify (case-sensitive, use only for
case-ignore-string syntax attrs)</description>
<comment name="author" xml:space="preserve">Lothar Haeger</comment>
<conditions>
<and>
<if-operation mode="nocase" op="equal">modify</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="attrlist" scope="policy">
<arg-string>
<token-text xml:space="preserve">Surname,Given Name</token-text>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="idv-values" scope="policy">
<arg-node-set>
<token-xpath expression="query:readObject($destQueryProcessor, association,
@dest-dn, @class-name, $attrlist)"/>
</arg-node-set>
</do-set-local-variable>
<do-for-each>
<arg-node-set>
<token-split delimiter=",">
<token-local-variable name="attrlist"/>
</token-split>
</arg-node-set>
<arg-actions>
<do-set-local-variable name="current-attr" scope="policy">
<arg-string>
<token-text xml:space="preserve">$current-node$</token-text>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="add-values" scope="policy">
<arg-node-set>
<token-op-attr name="$current-attr$"/>
</arg-node-set>
</do-set-local-variable>
<do-if>
<arg-conditions>
<and>
<if-xpath
op="true">modify-attr[@attr-name=$current-attr]/remove-all-values</if-xpath>
</and>
</arg-conditions>
<arg-actions>
<do-strip-op-attr name="$current-attr$"/>
<do-for-each>
<arg-node-set>
<token-xpath
expression="$idv-values//attr[@attr-name=$current-attr]/value[not(text()=$add-va
lues)]"/>
</arg-node-set>
<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>
</do-for-each>
</arg-actions>
<arg-actions>
<do-set-local-variable name="rem-values" scope="policy">
<arg-node-set>
<token-removed-attr name="$current-attr$"/>
</arg-node-set>
</do-set-local-variable>
<do-strip-op-attr name="$current-attr$"/>
<do-for-each>
<arg-node-set>
<token-xpath
expression="$idv-values//attr[@attr-name=$current-attr]/value[text()=$rem-values
and not(text()=$add-values)]"/>
</arg-node-set>
<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>
</do-for-each>
</arg-actions>
</do-if>
<do-for-each>
<arg-node-set>
<token-xpath
expression="$add-values[not(text()=$idv-values//attr[@attr-name=$current-attr]/v
alue)]"/>
</arg-node-set>
<arg-actions>
<do-add-dest-attr-value name="$current-attr$">
<arg-value type="string">
<token-text xml:space="preserve">$current-node$</token-text>
</arg-value>
</do-add-dest-attr-value>
</arg-actions>
</do-for-each>
</arg-actions>
</do-for-each>
</actions>
</rule>

This policy does not check the attribute syntax and it will only work as
expected as long as there's only one modify-attr node per attribute in your
event. You may have to clean up the resulting XDS a bit in some cases, too (at
least if you like your traces to look proper).

<?xml version="1.0" encoding="UTF-8"?><nds dtdversion="4.0" ndsversion="8.x">
<source>
<product version="4.7.0.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User" qualified-src-dn="o=dirXML Test\ou=Users\cn=User1">
<association>o=dirXML Test\ou=Users\cn=User1</association>
<modify-attr attr-name="Surname">
<remove-all-values/>
<add-value>
<value type="string">Stew</value>
</add-value>
</modify-attr>
<modify-attr attr-name="Given Name">
<remove-all-values/>
<add-value>
<value type="string">Jack</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
AIE-DriverAgent :Applying policy: %+C%14CNew Policy%-C.
AIE-DriverAgent : Applying to modify #1.
AIE-DriverAgent : Evaluating selection criteria for rule 'Publisher Optimize
Modify (case-sensitive, use only for CIS string syntax attrs)'.
AIE-DriverAgent : (if-operation equal "modify") = TRUE.
AIE-DriverAgent : Rule selected.
AIE-DriverAgent : Applying rule 'Publisher Optimize Modify (case-sensitive,
use only for CIS string syntax attrs)'.
AIE-DriverAgent : Action:
do-set-local-variable("attrlist",scope="policy","Surname,Given Name").
AIE-DriverAgent : arg-string("Surname,Given Name")
AIE-DriverAgent : token-text("Surname,Given Name")
AIE-DriverAgent : Arg Value: "Surname,Given Name".
AIE-DriverAgent : Action:
do-set-local-variable("idv-values",scope="policy",arg-node-set(token-xpath("quer
y:readObject($destQueryProcessor, association, @dest-dn, @class-name,
$attrlist)"))).
AIE-DriverAgent :
arg-node-set(token-xpath("query:readObject($destQueryProcessor, association,
@dest-dn, @class-name, $attrlist)"))
AIE-DriverAgent : token-xpath("query:readObject($destQueryProcessor,
association, @dest-dn, @class-name, $attrlist)")
AIE-DriverAgent : Query from policy
AIE-DriverAgent :
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product version="4.7.0.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="User" scope="entry">
<association>o=dirXML Test\ou=Users\cn=User1</association>
<read-attr attr-name="Surname"/>
<read-attr attr-name="Given Name"/>
</query>
</input>
</nds>
AIE-DriverAgent : Query from policy result
AIE-DriverAgent :
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product version="4.7.0.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<instance class-name="User" src-dn="data\users\mjstew">
<attr attr-name="Given Name">
<value type="string">Jack</value>
</attr>
<attr attr-name="Surname">
<value type="string">STEW</value>
</attr>
</instance>
</output>
</nds>
AIE-DriverAgent : Token Value: {<instance> @class-name = "User"
@src-dn = "data\users\mjstew"}.
AIE-DriverAgent : Arg Value: {<instance> @class-name = "User" @src-dn
= "data\users\mjstew"}.
AIE-DriverAgent : Action:
do-for-each(arg-node-set(token-split(",",token-local-variable("attrlist")))).
AIE-DriverAgent :
arg-node-set(token-split(",",token-local-variable("attrlist")))
AIE-DriverAgent : token-split(",",token-local-variable("attrlist"))
AIE-DriverAgent : token-split(",",token-local-variable("attrlist"))
AIE-DriverAgent : token-local-variable("attrlist")
AIE-DriverAgent : Token Value: "Surname,Given Name".
AIE-DriverAgent : Arg Value: "Surname,Given Name".
AIE-DriverAgent : Token Value: {"Surname","Given Name"}.
AIE-DriverAgent : Arg Value: {"Surname","Given Name"}.
AIE-DriverAgent : Performing actions for local-variable(current-node) =
"Surname".
AIE-DriverAgent : Action:
do-set-local-variable("current-attr",scope="policy","$current-node$").
AIE-DriverAgent : arg-string("$current-node$")
AIE-DriverAgent : token-text("$current-node$")
AIE-DriverAgent : Expanded variable reference '$current-node$'
to 'Surname'.
AIE-DriverAgent : Arg Value: "Surname".
AIE-DriverAgent : Action:
do-set-local-variable("add-values",scope="policy",arg-node-set(token-op-attr("$c
urrent-attr$"))).
AIE-DriverAgent : arg-node-set(token-op-attr("$current-attr$"))
AIE-DriverAgent : token-op-attr("$current-attr$")
AIE-DriverAgent : Expanded variable reference '$current-attr$'
to 'Surname'.
AIE-DriverAgent : Token Value: {<value> @type = "string"}.
AIE-DriverAgent : Arg Value: {<value> @type = "string"}.
AIE-DriverAgent : Action: do-if().
AIE-DriverAgent : Evaluating conditions.
AIE-DriverAgent : (if-xpath true
"modify-attr[@attr-name=$current-attr]/remove-all-values") = TRUE.
AIE-DriverAgent : Performing if actions.
AIE-DriverAgent : Action: do-strip-op-attr("$current-attr$").
AIE-DriverAgent : Expanded variable reference '$current-attr$'
to 'Surname'.
AIE-DriverAgent : Action:
do-for-each(arg-node-set(token-xpath("$idv-values//attr[@attr-name=$current-attr
]/value[not(text()=$add-values)]"))).
AIE-DriverAgent :
arg-node-set(token-xpath("$idv-values//attr[@attr-name=$current-attr]/value[not(
text()=$add-values)]"))
AIE-DriverAgent :
token-xpath("$idv-values//attr[@attr-name=$current-attr]/value[not(text()=$add-v
alues)]")
AIE-DriverAgent : Token Value: {<value> @type = "string"}.
AIE-DriverAgent : Arg Value: {<value> @type = "string"}.
AIE-DriverAgent : Performing actions for
local-variable(current-node) = <value> @type = "string".
AIE-DriverAgent : Action:
do-remove-dest-attr-value("$current-attr$","$current-node$").
AIE-DriverAgent : Expanded variable reference
'$current-attr$' to 'Surname'.
AIE-DriverAgent : arg-string("$current-node$")
AIE-DriverAgent : token-text("$current-node$")
AIE-DriverAgent : Expanded variable reference
'$current-node$' to 'STEW'.
AIE-DriverAgent : Arg Value: "STEW".
AIE-DriverAgent : Action:
do-for-each(arg-node-set(token-xpath("$add-values[not(text()=$idv-values//attr[@
attr-name=$current-attr]/value)]"))).
AIE-DriverAgent :
arg-node-set(token-xpath("$add-values[not(text()=$idv-values//attr[@attr-name=$c
urrent-attr]/value)]"))
AIE-DriverAgent :
token-xpath("$add-values[not(text()=$idv-values//attr[@attr-name=$current-attr]/
value)]")
AIE-DriverAgent : Token Value: {<value> @type = "string"}.
AIE-DriverAgent : Arg Value: {<value> @type = "string"}.
AIE-DriverAgent : Performing actions for
local-variable(current-node) = <value> @type = "string".
AIE-DriverAgent : Action:
do-add-dest-attr-value("$current-attr$","$current-node$").
AIE-DriverAgent : Expanded variable reference '$current-attr$'
to 'Surname'.
AIE-DriverAgent : arg-string("$current-node$")
AIE-DriverAgent : token-text("$current-node$")
AIE-DriverAgent : Expanded variable reference
'$current-node$' to 'Stew'.
AIE-DriverAgent : Arg Value: "Stew".
AIE-DriverAgent : Performing actions for local-variable(current-node) =
"Given Name".
AIE-DriverAgent : Action:
do-set-local-variable("current-attr",scope="policy","$current-node$").
AIE-DriverAgent : arg-string("$current-node$")
AIE-DriverAgent : token-text("$current-node$")
AIE-DriverAgent : Expanded variable reference '$current-node$'
to 'Given Name'.
AIE-DriverAgent : Arg Value: "Given Name".
AIE-DriverAgent : Action:
do-set-local-variable("add-values",scope="policy",arg-node-set(token-op-attr("$c
urrent-attr$"))).
AIE-DriverAgent : arg-node-set(token-op-attr("$current-attr$"))
AIE-DriverAgent : token-op-attr("$current-attr$")
AIE-DriverAgent : Expanded variable reference '$current-attr$'
to 'Given Name'.
AIE-DriverAgent : Token Value: {<value> @type = "string"}.
AIE-DriverAgent : Arg Value: {<value> @type = "string"}.
AIE-DriverAgent : Action: do-if().
AIE-DriverAgent : Evaluating conditions.
AIE-DriverAgent : (if-xpath true
"modify-attr[@attr-name=$current-attr]/remove-all-values") = TRUE.
AIE-DriverAgent : Performing if actions.
AIE-DriverAgent : Action: do-strip-op-attr("$current-attr$").
AIE-DriverAgent : Expanded variable reference '$current-attr$'
to 'Given Name'.
AIE-DriverAgent : Action:
do-for-each(arg-node-set(token-xpath("$idv-values//attr[@attr-name=$current-attr
]/value[not(text()=$add-values)]"))).
AIE-DriverAgent :
arg-node-set(token-xpath("$idv-values//attr[@attr-name=$current-attr]/value[not(
text()=$add-values)]"))
AIE-DriverAgent :
token-xpath("$idv-values//attr[@attr-name=$current-attr]/value[not(text()=$add-v
alues)]")
AIE-DriverAgent : Token Value: {}.
AIE-DriverAgent : Arg Value: {}.
AIE-DriverAgent : Action:
do-for-each(arg-node-set(token-xpath("$add-values[not(text()=$idv-values//attr[@
attr-name=$current-attr]/value)]"))).
AIE-DriverAgent :
arg-node-set(token-xpath("$add-values[not(text()=$idv-values//attr[@attr-name=$c
urrent-attr]/value)]"))
AIE-DriverAgent :
token-xpath("$add-values[not(text()=$idv-values//attr[@attr-name=$current-attr]/
value)]")
AIE-DriverAgent : Token Value: {}.
AIE-DriverAgent : Arg Value: {}.
AIE-DriverAgent :Policy returned:
AIE-DriverAgent :
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product version="4.7.0.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User" qualified-src-dn="o=dirXML
Test\ou=Users\cn=User1">
<association>o=dirXML Test\ou=Users\cn=User1</association>
<modify-attr attr-name="Surname">
<remove-value>
<value type="string">STEW</value>
</remove-value>
</modify-attr>
<modify-attr attr-name="Surname">
<add-value>
<value type="string">Stew</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>

--
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
mjstew Frequent Contributor.
Frequent Contributor.

Re: Case Sensitivity of "Virtual" Attributes

Hi David! Yes, long time no holler!

Sorry for breaking protocol, but I don't have a level 3 trace of this yet. I'm starting to work a card to figure out why this problems was happening.

What you're saying makes sense: the optimizer will merge the attributes in flight with the ones at rest in the database. If an attribute is case ignore string, it's going to ignore the change and use the attribute at rest, right? Can you please confirm that optimization behavior? That's what I've observed but not seen documented.

In what way could you work around the optimizer? I thought you couldn't ...
0 Likes
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

On 6/28/2018 12:24 PM, mjstew wrote:
>
> Hi David! Yes, long time no holler!
>
> Sorry for breaking protocol, but I don't have a level 3 trace of this
> yet. I'm starting to work a card to figure out why this problems was
> happening.
>
> What you're saying makes sense: the optimizer will merge the attributes
> in flight with the ones at rest in the database. If an attribute is
> case ignore string, it's going to ignore the change and use the
> attribute at rest, right? Can you please confirm that optimization
> behavior? That's what I've observed but not seen documented.
>
> In what way could you work around the optimizer? I thought you couldn't


In the filter, there is a flag about Optimize modify at the attribute
level.

0 Likes
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

geoffc;2483233 wrote:
On 6/28/2018 12:24 PM, mjstew wrote:
>
> Hi David! Yes, long time no holler!
>
> Sorry for breaking protocol, but I don't have a level 3 trace of this
> yet. I'm starting to work a card to figure out why this problems was
> happening.
>
> What you're saying makes sense: the optimizer will merge the attributes
> in flight with the ones at rest in the database. If an attribute is
> case ignore string, it's going to ignore the change and use the
> attribute at rest, right? Can you please confirm that optimization
> behavior? That's what I've observed but not seen documented.
>
> In what way could you work around the optimizer? I thought you couldn't


In the filter, there is a flag about Optimize modify at the attribute
level.


I don't recall that working on a case-only change to a case insensitive attribute.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

dgersic wrote:

> I don't recall that working on a case-only change to a case insensitive
> attribute.


Sure it does. Here's a trace with Optimize Modify enabled (default setting for
all attributes when added to filter):

[06/28/18 19:17:29.398]:AIE-SyncEngine PT:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify dest-dn="\DEV-TREE-45\data\idm\users\OETEST-User01"
event-id="idv45#20180628171729#1#1:0521ab60-d12c-4b57-4d93-60ab21052cd1">
<modify-attr attr-name="employeeType">
<remove-value>
<value type="string">consultant</value>
</remove-value>
</modify-attr>
<modify-attr attr-name="employeeType">
<add-value>
<value type="string">Consultant</value>
</add-value>
</modify-attr>
<operation-data channel="pub" log-id="data\idm\users\OETEST-User01"/>
</modify>
</input>
</nds>
[06/28/18 19:17:29.399]:AIE-SyncEngine PT:No schema mapping policies.
[06/28/18 19:17:29.399]:AIE-SyncEngine PT:Resolving association references.
[06/28/18 19:17:29.399]:AIE-SyncEngine PT:No event transformation policies.
[06/28/18 19:17:29.400]:AIE-SyncEngine PT:Applying publisher filter.
[06/28/18 19:17:29.400]:AIE-SyncEngine PT:Publisher processing modify for .
[06/28/18 19:17:29.400]:AIE-SyncEngine PT:Reading relevant attributes from
\DEV-TREE-45\data\idm\users\OETEST-User01.
[06/28/18 19:17:29.400]:AIE-SyncEngine PT:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="User"
dest-dn="\DEV-TREE-45\data\idm\users\OETEST-User01" scope="entry">
<read-attr attr-name="employeeType"/>
<read-attr attr-name="Object Class"/>
</query>
</input>
</nds>
[06/28/18 19:17:29.401]:AIE-SyncEngine PT:Pumping XDS to eDirectory.
[06/28/18 19:17:29.401]:AIE-SyncEngine PT:Performing operation query for
\DEV-TREE-45\data\idm\users\OETEST-User01.
[06/28/18 19:17:29.401]:AIE-SyncEngine PT:--JCLNT--
\DEV-TREE-45\system\driverset1\AIE-SyncEngine - Publisher : Duplicating :
context = 44368023, tempContext = 44367962
[06/28/18 19:17:29.402]:AIE-SyncEngine PT:--JCLNT--
\DEV-TREE-45\system\driverset1\AIE-SyncEngine - Publisher : Calling free on
tempContext = 44367962
[06/28/18 19:17:29.402]:AIE-SyncEngine PT:Read result:
[06/28/18 19:17:29.402]:AIE-SyncEngine PT:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<instance class-name="User" event-id="0"
qualified-src-dn="O=data\OU=idm\OU=users\CN=OETEST-User01"
src-dn="\DEV-TREE-45\data\idm\users\OETEST-User01" src-entry-id="42251">
<association
state="associated">{538B51E2-5C60-4ade-2696-E2518B53605C}</association>
<attr attr-name="employeeType">
<value timestamp="1530205945#14" type="string">consultant</value>
</attr>
<attr attr-name="Object Class">
<value timestamp="1530205940#13" type="string">User</value>
<value timestamp="1530205940#14" type="string">Organizational
Person</value>
<value timestamp="1530205940#15" type="string">Person</value>
<value timestamp="1530205940#16"
type="string">ndsLoginProperties</value>
<value timestamp="1530205940#17" type="string">Top</value>
</attr>
</instance>
<status event-id="0" level="success"></status>
</output>
</nds>
[06/28/18 19:17:29.404]:AIE-SyncEngine PT:Optimize Modify determined operation
not needed.
[06/28/18 19:17:29.404]:AIE-SyncEngine PT:
DirXML Log Event -------------------
Driver: \DEV-TREE-45\system\driverset1\AIE-SyncEngine
Channel: Publisher
Object: (\DEV-TREE-45\data\idm\users\OETEST-User01)
Status: Success

With Optimize Modify disables, the trace continues as follows:

(same as above, then...)
[06/28/18 19:22:53.372]:AIE-SyncEngine PT:Optimize Modify returned:
[06/28/18 19:22:53.372]:AIE-SyncEngine PT:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User"
dest-dn="\DEV-TREE-45\data\idm\users\OETEST-User01"
event-id="idv45#20180628172253#1#1:0521ab60-d12c-4b57-4d93-60ab21052cd1">
<operation-data channel="pub" log-id="data\idm\users\OETEST-User01"/>
<modify-attr attr-name="employeeType">
<remove-value>
<value type="string">consultant</value>
</remove-value>
</modify-attr>
<modify-attr attr-name="employeeType">
<add-value>
<value type="string">Consultant</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
[06/28/18 19:22:53.373]:AIE-SyncEngine PT:Applying command transformation
policies.
(...some more policies that do not change the event in this case, and
finally...)
[06/28/18 19:22:53.381]:AIE-SyncEngine PT:Policy returned:
[06/28/18 19:22:53.381]:AIE-SyncEngine PT:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User"
dest-dn="\DEV-TREE-45\data\idm\users\OETEST-User01"
event-id="idv45#20180628172253#1#1:0521ab60-d12c-4b57-4d93-60ab21052cd1">
<modify-attr attr-name="employeeType">
<remove-value>
<value type="string">consultant</value>
</remove-value>
</modify-attr>
<modify-attr attr-name="employeeType">
<add-value>
<value type="string">Consultant</value>
</add-value>
</modify-attr>
<operation-data channel="pub" log-id="data\idm\users\OETEST-User01"/>
</modify>
</input>
</nds>
[06/28/18 19:22:53.383]:AIE-SyncEngine PT:Filtering out notification-only
attributes.
[06/28/18 19:22:53.383]:AIE-SyncEngine PT:Pumping XDS to eDirectory.
[06/28/18 19:22:53.383]:AIE-SyncEngine PT:Performing operation modify for
\DEV-TREE-45\data\idm\users\OETEST-User01.
[06/28/18 19:22:53.383]:AIE-SyncEngine PT:--JCLNT--
\DEV-TREE-45\system\driverset1\AIE-SyncEngine - Publisher : Duplicating :
context = 44367966, tempContext = 44367982
[06/28/18 19:22:53.384]:AIE-SyncEngine PT:Modifying entry
\DEV-TREE-45\data\idm\users\OETEST-User01.
[06/28/18 19:22:53.389]:AIE-SyncEngine PT:--JCLNT--
\DEV-TREE-45\system\driverset1\AIE-SyncEngine - Publisher : Calling free on
tempContext = 44367982
[06/28/18 19:22:53.390]:AIE-SyncEngine PT:
DirXML Log Event -------------------
Driver: \DEV-TREE-45\system\driverset1\AIE-SyncEngine
Channel: Publisher
Object: \DEV-TREE-45\data\idm\users\OETEST-User01
Status: Success

Case changed in Edirectory as a result from "consultant" to "Consultant". This
also works with mandatory attributes like Surname:

[06/28/18 19:39:53.948]:AIE-SyncEngine PT:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify class-name="User"
dest-dn="\DEV-TREE-45\data\idm\users\OETEST-User01"
event-id="idv45#20180628173953#1#1:ad4ef75d-126e-4ab2-aa9c-5df74ead6e12">
<modify-attr attr-name="Surname">
<remove-value>
<value type="string">GERSIC</value>
</remove-value>
</modify-attr>
<modify-attr attr-name="Surname">
<add-value>
<value type="string">Gersic</value>
</add-value>
</modify-attr>
<operation-data channel="pub" log-id="data\idm\users\OETEST-User01"/>
</modify>
</input>
</nds>
[06/28/18 19:39:53.949]:AIE-SyncEngine PT:Filtering out notification-only
attributes.
[06/28/18 19:39:53.949]:AIE-SyncEngine PT:Pumping XDS to eDirectory.
[06/28/18 19:39:53.950]:AIE-SyncEngine PT:Performing operation modify for
\DEV-TREE-45\data\idm\users\OETEST-User01.
[06/28/18 19:39:53.950]:AIE-SyncEngine PT:--JCLNT--
\DEV-TREE-45\system\driverset1\AIE-SyncEngine - Publisher : Duplicating :
context = 44367962, tempContext = 44367965
[06/28/18 19:39:53.950]:AIE-SyncEngine PT:Modifying entry
\DEV-TREE-45\data\idm\users\OETEST-User01.
[06/28/18 19:39:53.955]:AIE-SyncEngine PT:--JCLNT--
\DEV-TREE-45\system\driverset1\AIE-SyncEngine - Publisher : Calling free on
tempContext = 44367965
[06/28/18 19:39:53.956]:AIE-SyncEngine PT:
DirXML Log Event -------------------
Driver: \DEV-TREE-45\system\driverset1\AIE-SyncEngine
Channel: Publisher
Object: \DEV-TREE-45\data\idm\users\OETEST-User01
Status: Success

So flipping the switch in filter makes it work usually, it's just not efficient
in some use cases because it will also prevent optimization of case-exact value
matches and some apps are stupid enough to deliver each and every user with all
the same attributes every hour... - that's why case-exact optimization in
policy makes sense sometimes.

--
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
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

mjstew;2483232 wrote:
Hi David! Yes, long time no holler!

Sorry for breaking protocol, but I don't have a level 3 trace of this yet. I'm starting to work a card to figure out why this problems was happening.

What you're saying makes sense: the optimizer will merge the attributes in flight with the ones at rest in the database. If an attribute is case ignore string, it's going to ignore the change and use the attribute at rest, right? Can you please confirm that optimization behavior? That's what I've observed but not seen documented.

In what way could you work around the optimizer? I thought you couldn't ...


I don't recall where I first saw this documented. Possibly it was one of Father Ramon's posts, way back when. Anyway, "case insensitive" means what it says on the tin, there's no difference between "bob" and "Bob", so case only changes get optimized away on the publisher. But, where there's a will, there's a way, right?

I most often encounter this in DelimText drivers being used as a pseudo HR system. Dump a CSV of users, publish events, simple. Why didn't "bob" change to "Bob" when we published him?

So I add something like this. On the publisher event transform, I squirrel away a copy of the attribute:


<do-if>
<arg-conditions>
<and>
<if-op-attr name="Given Name" op="available"/>
</and>
</arg-conditions>
<arg-actions>
<do-clone-op-attr dest-name="CIGivenName" src-name="Given Name"/>
</arg-actions>
<arg-actions/>
</do-if>


then, later, after the publisher optimizer has had its chance to do what it does, on the publisher command transform, something like:


<do-set-local-variable name="SRCGivenName" scope="policy">
<arg-string>
<token-op-attr name="CIGivenName"/>
</arg-string>
</do-set-local-variable>
<do-if>
<arg-conditions>
<and>
<if-op-attr name="CIGivenName" op="available"/>
<if-dest-attr mode="case" name="Given Name" op="not-equal">$SRCGivenName$</if-dest-attr>
</and>
</arg-conditions>
<arg-actions>
<do-set-dest-attr-value name="Given Name">
<arg-value type="string">
<token-local-variable name="SRCGivenName"/>
</arg-value>
</do-set-dest-attr-value>
</arg-actions>
<arg-actions/>
</do-if>


I added the case sensitive compare to attempt to do what the optimizer is trying to do, prevent unnecessary writes to the database. Reads are faster than writes, so only write if needed.

You could wrap a loop around this, to handle a bunch of attributes, maybe list them in a GCV. I guess you could probably even loop through the whole document and do it with every attribute in it, if you needed to do that.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

mjstew wrote:

> If an attribute is
> case ignore string, it's going to ignore the change and use the
> attribute at rest, right? Can you please confirm that optimization
> behavior? That's what I've observed but not seen documented.


What's not documented (or I just cannot find it) is that the Publisher Optimize
Modify feature relies on the attribute's syntax's matching rules, which for
case-ignore-string attributes is ignoring case (surprise, surprise):

"Two case ignore strings match for equality when they are of the same length
and their corresponding characters are identical in all respects except that of
case. For example, as case ignore strings, “Dundee” and “DUNDEE” would be equal.

When comparing case ignore strings, the following spaces are not significant:

Leading spaces (precede the first printing character)

Trailing spaces (follow the last printing character)

Multiple consecutive internal spaces (equivalent to a single space
character)

In matching attributes that conform to this syntax, eDirectory omits those
spaces that are not significant (as defined above). eDirectory stores
insignificant spaces with the attribute value."

(-->
https://www.novell.com/documentation/developer/ndslib/schm_enu/data/sdk5561.html
)

But that does not mean that Edir does not *store* the values case exact. "Stew"
and "stew" are still two different values in Edir and any client actually
reading and comparing them itself against other values that differ just in
case, can see the difference and opt to change the case stored in Edir.
Just if you ask Edir "Does the value you have stored equals 'Stew'?" it will
return "true" even if it is actually stored as "stew". And this is what the
Publisher Optimize Modify feature does. It does NOT actually read values off
Edir to compare them against the values from the current operation, you need to
do this in policy if that's what you need.

Sounds like a due enhancement request...

--
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
Knowledge Partner
Knowledge Partner

Re: Case Sensitivity of "Virtual" Attributes

As always, please post a level three (3) trace so we can fully understand
what you mean. I am not sure I follow everything.

If you are merely changing the case of a name, then you may need to add a
bit of logic to make that possible. If the attribute is case-ignore
string then a change to it of ONLY case may be ignored by a lot of tools,
even things like iManager. Since something like Surname is mandatory you
cannot remove it and then add it back, but you could change it in a
non-case-only way (append a '1', then remove it when setting the correct
value with correct case). With something like Given Name you could remove
it and add it back, of course.

IDM will, I think, pick up case events on an attribute when ONLY the case
is changing, but whether or not the directory will accept back a case-only
change is perhaps another question, as the engine or directory may decide
to optimize out something that cannot be seen as a non-case change on a
case-ignore attribute (as opposed to a case exact attribute).


--
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: Case Sensitivity of "Virtual" Attributes

ab wrote:

> Since something like Surname is mandatory you
> cannot remove it and then add it back


I think it work as long as it's part of the same command. Pretty sure I've seen
both

<modify-attr attr-name="Surname">
<remove-all-values/>
<add-value>
<value type="string">Burgemeister</value>
</add-value>
</modify-attr>

and

<modify-attr attr-name="Surname">
<remove-value>
<value type="string">BurgeMeister</value>
</remove-value>
<add-value>
<value type="string">Burgemeister</value>
</add-value>
</modify-attr>

resulting in a case-only change of Surname. Problem is that you won't ever see
such a command in a publisher command transform with the default filter
stetting of publisher-optimize-modify="true". Should work ootb when writing
back to IDV from a subscriber policy in a NULL driver, though.

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