Active Directory Driver: only one value retained in multi valued attribute after merge

Hello,

Note: I submit this problem here because I already have three backlogged IDM cases with MicroFocus support since the beginning of March and not much is happening on that front . Thus I am turning to the community for this new issue.

In an Active Directory driver the multivalued vault employeeType attribute is mapped to another multivalued application attribute, e.g. carLicense. This because in AD, employeeType is single valued and we would like to preserve the multivalued property of the attribute.

When testing the driver, in this case with a migrate from vault of an entry that has three values in employeeType, after the merge only one value is retained (i.e. before the attribute mapping or any rule is applied). I expected that all three values would be kept.

- Has anybody seen such a behaviour? What could be the cause?

From Designer I double checked that the vault and application schema were up to date, and that both attributes were known to be multi valued.

You'll find in attachment a relevant extract of the AD driver log (trace level 4) showing the problem.
The vault directory schema shows employeeType to be multi valued:

attributeTypes: ( 2.16.840.1.113730.3.1.4 NAME 'employeeType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} )

Context:
Identity Manager 4.7.4.0 SE
Active Directory driver 4.1.0.0
NetIQ eDirectory 9.2.1 v40202.00

Thanks in advance for your insights on this issue!

Dominique

 

  • My guess is driver shim might have integrated logic to turn it into a single-valued attribute or some important part of the trace is missing (I think not).
    If that is the case I would write a policy that queries employeeType attribute in IDV and sets all the values manually on every employeeType changing event.
    Another option is setting auxiliary multivalued attribute (for example auxEmployeeType) in Null/Business Logic driver and then mapping that auxiliary attribute (auxEmployeeType) to carLicense attribute in AD (shim then should work as expected). Before you introduce new aux attribute try it with any other IDV attribute that is already multi-valued in AD and map it to carLicense attribute in AD.
    Of course, these are just quick ideas. The second one is better in a way that you don't have to compare existing values in attributes and shim optimizes your writes to AD (if only one value is changed in IDV only one is removed and added in AD, on the first option removing all values and adding all of the current ones would be recommended).
  •  

    (Corrected)

    Could you share an extract of the Schema Mapping for this driver (focusing on the employeeType attribute mapping) and the mapped attribute syntax from Active Directory.

    As this is a migrate (sync) event with an association, you have shown the snippet of the response from eDirectory before the merge, do you have a query response from AD of the existing object? Before the merge is calculated, there will be a query to AD as well as the query to eDirectory. Then the merge processor will generate the updates to eDirectory and to the Application (AD) as two separate

    Having the schema mapping and the query results from AD may shed some light on what has happened.

    Cheers,

    D

  • Hello Zan,

    thanks for your answer:

    > My guess is driver shim might have integrated logic to turn it into a single-valued attribute

    If it is the case I would consider this as a bug: the driver shim should not preclude how the attribute employeeType is going to be handled.  If a multi-valued to single value mapping should occur, it is only when the mapping rule is applied and the target attribute is single valued. In the case I described the "command transformation" rules have not yet been applied and could very well need all the values (but can't because they were removed at the previous step because of the problem discussed here).

    > or some important part of the trace is missing (I think not).

    In the attached log extract, the missing parts are indicated by "...". All the other lines are sequential, in particular there is nothing more logged between the "ST:Read result:" part and the "ST:Updating application with eDirectory values." part (at trace level 4).


    If that is the case I would write a policy that queries employeeType attribute in IDV and sets all the values manually on every employeeType changing event.

    The problem does not occur for a modify event: Command transformation rules have access to all values and the attribute mapping rule map all the values. Since it seems to happen only for a sync event, may be a simple rule that copies the attribute from the source, triggered only in the sync case (from-merge="true"), could be sufficient.

    > Another option is setting auxiliary multivalued attribute (for example auxEmployeeType) in Null/Business Logic driver and then mapping that auxiliary attribute (auxEmployeeType) to carLicense attribute in AD (shim then should work as expected). Before you introduce new aux attribute try it with any other IDV attribute that is already multi-valued in AD and map it to carLicense attribute in AD.

    Clever solution!  I was thinking only inside (the driver) box!

    > Of course, these are just quick ideas. The second one is better in a way that you don't have to compare existing values in attributes and shim optimizes your writes to AD (if only one value is changed in IDV only one is removed and added in AD, on the first option removing all values and adding all of the current ones would be recommended).

    As said above the problem does seem to occur only for a sync event, so the auxiliary attribute workaround would not be necessary.

    I was hoping to have overlooked some fact that would explain the problem, but the more I tinker with it the more I am convinced it is a bug, and, unfortunately, some workaround like the two solutions you describe is necessary to compensate.

    For other readers: I would still be interested if you have observed the same problem!

    Thanks again, Zan, for your advice.

    Dominique

  • Hello D,

    thanks for your message.

    Here is the attribute mapping and Active Directory attribute schema definitions (vanilla AD):

    <attr-name>
    <nds-name>employeeType</nds-name>
    <app-name>carLicense</app-name>
    </attr-name>
    dn: CN=carLicense,CN=Schema,CN=Configuration,DC=isis-klif,DC=unige,DC=ch
    attributeID: 2.16.840.1.113730.3.1.1
    isSingleValued: FALSE
    lDAPDisplayName: carLicense

    dn: CN=Employee-Type,CN=Schema,CN=Configuration,DC=isis-klif,DC=unige,DC=ch
    attributeID: 1.2.840.113556.1.2.613
    isSingleValued: TRUE
    lDAPDisplayName: employeeType

    The characteristics of the attributes are known to the driver (cf. first lines of the attached log extract showing these application "user" class attribute definitions):

    <class-def class-name="user" container="true">
    ...
    <attr-def asn1id="" attr-name="carLicense" case-sensitive="false" multi-valued="true" naming="false" read-only="false" required="false" type="string"/>
    ...
    <attr-def asn1id="" attr-name="employeeType" case-sensitive="false" multi-valued="false" naming="false" read-only="false" required="false" type="string"/>

    As for the query of the attributes in AD, I have never seen one for a subscriber sync event  (here or in other drivers) and I don't believe there should be any: the idea of a migrate is to ignore and reset the existing values in the application's  entry for all the synced attributes. The only query that could occur is a schema query for carLicense, but as shown in the log this occurs  before, once for all when the driver is reloaded, and at the sync time it is already known. At least that is my belief!
    Also, as written in my answer to Zan's post, the attached log extract does not leave out any important information around the crucial moment ("Updating application with eDirectory values").


    I realize now that I should have used the term "sync" instead of  "merge" in the subject of this discussion.
    Because, as I understand it, there is no real merge operation occurring at the stage I described. I used "merge" by habit because that is the terminology found in the log ( c.f. "Merging eDirectory and application values" and the 'from-merge="true"' parameter in the resulting "modify" even that I usually turn into a "FromMerge" variable to be used in some rule conditions) . I wonder why such a misleading terminology is used by IDM.

    But there might be something in my context (e.g. versions) that causes the problem:
    - I would be interested if you can reproduce the problem (or not) in your AD driver!

    Thanks again for your contribution!

    Regards,
    Dominique

  • Hi Dominique,
    It can help, if you will share an end-to-end trace of your problematic transaction.

    I saw "similar" situations with different drivers when multi-value attribute mapped to another multivalued attribute, but the driver "delivered" a single value. (I saw this issue with the eDir driver).
    At the same time, I saw "opposite" behavior, when multiple values pushed by the "from-merge" operation to a single value attribute.

    When you have multiple values in the same attribute, you can't use the "Set-Destination-Attribute" token, as it expected a single string.

    You can use your own custom logic for generating proper doc.
    High-level logic:
    1. Store multivalue in nodeset var.
    2. In the for-each cycle:
    a. First value: Set-Destination-Attribute
    b. Second (and other values): Add-Destination-Attribute.

    This way, you will be able to deliver all values from multivalue attribute to the target system.

  •  wrote:

    As for the query of the attributes in AD, I have never seen one for a subscriber sync event  (here or in other drivers) and I don't believe there should be any: the idea of a migrate is to ignore and reset the existing values in the application's  entry for all the synced attributes. 


    Not really, and that's why it's called "merge" and not "reset". Merge behavior actually depends on the filter settings for the attribute in question and the docs have more details at https://www.netiq.com/documentation/identity-manager-developer/dtd-documentation/dirxmlfilter/filter-attr.html

    If an attribute is synchronized bi-directional, the engine queries both sides and then consults both sides' schema to determine which values should end up where. It then uses the known values from both sides to make the necessary changes to achieve the desired result. I'm not sure if @publisher-optimize-modify is taken into consideration for modifications to the IDV here (there was a long-standing bug open about IDM ignoring it during merges and with MF's move away from Bugzilla, I cannot see it's current status anymore, unfortunately).

    If an attribute is synchronized uni-directional, the source's values and the target schema properties determine what should end up on the target side. Still the engine should query the target to see which modifications are actually needed to get there, iirc.

    The latter case seems to fit your description, yet we see in the trace only a single value for employeeType (later mapped to carLicense) as output of the merge processor. My gues would be that the AD schema does not get read properly by the driver or the engine does not take it into consideration appropriately. An (anonymized)  full trace of an application schema refresh (can be triggered from within Designer), driver startup (so we'll see the filter, schema map, GCVs etc) and complete processing of a sync event in trace level 3 or higher should help to understand what's your exact situation.

  • Hello al_b,

    Thanks for your message!
    I will provide a full trace soon.

    Thanks for the hints for copying of a multi valued attribute . We have something like that in place, but IMHO it is a workaround and should not be necessary for a simple attribute (employeeType)  to attribute (carLicense) mapping.
    Note,: In the same line you describe, we also have a rule to concatenate the values of employeeType to a single value attribute (Active Directory employeeType).

    Regards.

  • Hi Lothar,

    Thanks for your detailed reply!
    I was about to answer when the community site froze.

    You are absolutely right: in my answer I overlooked the bi-directional driver case. My excuse is that in our setting most drivers are exclusively one way (essentially one publisher and a few subscriber drivers). But the AD driver in question has some bi-directionality (originally just so that the AD objectGUID can be used in the association, later also for  the password).
    Thanks for gently showing me were I was wrong!

    In order to show the problem without interference from other policies a subscriber only test driver was created that just maps IDV's employeeType to AD's carLicense.

    Here is the filter definition:

    <filter>
            <filter-class class-name="unigeChUser" publisher="ignore" publisher-create-homedir="false" publisher-track-template-member="false" subscriber="sync">
                    <filter-attr attr-name="employeeType" merge-authority="default" publisher="ignore" publisher-optimize-modify="true" subscriber="sync"/>
            </filter-class>
    </filter>


    And the schema mapping:

    <attr-name-map>
            <class-name>
                    <nds-name>unigeChUser</nds-name>
                    <app-name>user</app-name>
            </class-name>
            <attr-name class-name="unigeChUser">
                    <nds-name>employeeType</nds-name>
                    <app-name>carLicense</app-name>
            </attr-name>
    </attr-name-map>


    You'll find the application schema in attachment.   DirXML-ApplicationSchema.xml

    You will see in the new attached full log ADtest.log.txt           that, in effect, the sync event produces a reset (remove + add):


          <modify-attr attr-name="employeeType">
            <remove-all-values/>
            <add-value>
              <value timestamp="1525727585#116" type="string">ASSISTANT</value>
            </add-value>
          </modify-attr>


    I still believe that the result of the sync (aka merge) should not have one value, because at that stage, i.e. before attribute mapping, the Command transformation rules should be able to access all the values of the source employeeType attribute (which is the case for a modify event) even if the target attribute is single-valued, even more so if it is multi-valued.


    Regards,
    Dominique

  • That is indeed strange:

    [04/29/21 22:27:27.455]:ADtest ST:Reading relevant attributes from \IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455.
    [04/29/21 22:27:27.456]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <query class-name="unigeChUser" dest-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" dest-entry-id="94400" scope="entry">
          <read-attr attr-name="employeeType"/>
        </query>
      </input>
    </nds>
    [04/29/21 22:27:27.457]:ADtest ST:Pumping XDS to eDirectory.
    [04/29/21 22:27:27.457]:ADtest ST:Performing operation query for \IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455.
    [04/29/21 22:27:27.457]:ADtest ST:--JCLNT-- \IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest : Duplicating : context = 728760499, tempContext = 728760497
    [04/29/21 22:27:27.458]:ADtest ST:--JCLNT-- \IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest : Calling free on tempContext = 728760497
    [04/29/21 22:27:27.459]:ADtest ST:Read result:
    [04/29/21 22:27:27.459]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <output>
        <instance class-name="unigeChUser" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400">
          <association state="migrate">d624a9c35a4a4a47a1b30c0a35dba5a2</association>
          <attr attr-name="employeeType">
            <value timestamp="1525727585#116" type="string">ASSISTANT</value>
            <value timestamp="1525727585#117" type="string">PAT</value>
            <value timestamp="1525727585#118" type="string">ETUDIANT</value>
          </attr>
        </instance>
        <status level="success"></status>
      </output>
    </nds>
    [04/29/21 22:27:27.461]:ADtest ST:Updating application with eDirectory values.
    [04/29/21 22:27:27.461]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <modify class-name="unigeChUser" event-id="idmserver1#20210429202727#3#1:151cac06-f15a-4fe0-9e95-06ac1c155af1" from-merge="true" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400">
          <association>d624a9c35a4a4a47a1b30c0a35dba5a2</association>
          <modify-attr attr-name="employeeType">
            <remove-all-values/>
            <add-value>
              <value timestamp="1525727585#116" type="string">ASSISTANT</value>
            </add-value>
          </modify-attr>
        </modify>
      </input>
    </nds>

    Could you please try and set the merge-authority in the filter to "edir"? Not much hope it's solving this, but it does make a difference in merges from sync events, so maybe you're lucky...

  • Hello Lothar,

    thanks for the suggestion, I had tried it when I first encountered the problem but unfortunately  setting the merge-authority in the filter to "edir" does not change anything.
    I also tested with different values in the application AD directory, including the same three values as in the IDV. i.e. it does not seem to matter what the values of carLicense are: in all cases only one IDV value is retained after a sync (no "merging" or intersection occurs).


    To compare, another multi-valued attribute was added to the test: Telephone Number. Similarly to employeeType the naturally corresponding AD attribute, telephoneNumber is also single valued. Also similarly, in this test, it is mapped to a multivalued attribute: businessCategory. And, strangely, in this case the sync works properly: all values are transmitted cf.

    ADtest.log4.txt
    [04/30/21 17:48:39.250]:ADtest ST:Start transaction.
    [04/30/21 17:48:39.250]:ADtest ST:type(resync-entry)entry-id(94400) dn(\T=IDM-TREE-LAB\C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455) class-id(-1) class-name(null)
    [04/30/21 17:48:39.251]:ADtest ST:Processing events for transaction.
    [04/30/21 17:48:39.252]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <sync cached-time="20210430154839.234Z" class-name="unigeChUser" event-id="idmserver1#20210430154839#3#1:274b639d-bede-4786-ad50-9d634b27debe" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400" timestamp="0#0">
          <association state="migrate">d624a9c35a4a4a47a1b30c0a35dba5a2</association>
        </sync>
      </input>
    </nds>
    [04/30/21 17:48:39.253]:ADtest ST:No event transformation policies.
    [04/30/21 17:48:39.253]:ADtest ST:Subscriber processing sync for \IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455.
    [04/30/21 17:48:39.254]:ADtest ST:Merging eDirectory and application values.
    [04/30/21 17:48:39.254]:ADtest ST:Reading relevant attributes from \IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455.
    [04/30/21 17:48:39.254]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <query class-name="unigeChUser" dest-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" dest-entry-id="94400" scope="entry">
          <read-attr attr-name="employeeType"/>
          <read-attr attr-name="Telephone Number"/>
        </query>
      </input>
    </nds>
    [04/30/21 17:48:39.255]:ADtest ST:Pumping XDS to eDirectory.
    [04/30/21 17:48:39.255]:ADtest ST:Performing operation query for \IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455.
    [04/30/21 17:48:39.256]:ADtest ST:--JCLNT-- \IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest : Duplicating : context = 728760489, tempContext = 728760465
    [04/30/21 17:48:39.257]:ADtest ST:--JCLNT-- \IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest : Calling free on tempContext = 728760465
    [04/30/21 17:48:39.257]:ADtest ST:Read result:
    [04/30/21 17:48:39.257]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <output>
        <instance class-name="unigeChUser" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400">
          <association state="migrate">d624a9c35a4a4a47a1b30c0a35dba5a2</association>
          <attr attr-name="employeeType">
            <value timestamp="1619795777#15" type="string">ASSISTANT</value>
            <value timestamp="1619795777#16" type="string">PAT</value>
            <value timestamp="1619795777#17" type="string">ETUDIANT</value>
          </attr>
          <attr attr-name="Telephone Number">
            <value timestamp="1619797641#15" type="teleNumber">+41 22 ab ghij</value>
            <value timestamp="1619797641#16" type="teleNumber">+41 22 ab cdef</value>
          </attr>
        </instance>
        <status level="success"></status>
      </output>
    </nds>
    [04/30/21 17:48:39.260]:ADtest ST:Updating application with eDirectory values.
    [04/30/21 17:48:39.260]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <modify class-name="unigeChUser" event-id="idmserver1#20210430154839#3#1:274b639d-bede-4786-ad50-9d634b27debe" from-merge="true" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400">
          <association>d624a9c35a4a4a47a1b30c0a35dba5a2</association>
          <modify-attr attr-name="employeeType">
            <remove-all-values/>
            <add-value>
              <value timestamp="1619795777#15" type="string">ASSISTANT</value>
            </add-value>
          </modify-attr>
          <modify-attr attr-name="Telephone Number">
            <remove-all-values/>
            <add-value>
              <value timestamp="1619797641#15" type="teleNumber">+41 22 ab ghij</value>
              <value timestamp="1619797641#16" type="teleNumber">+41 22 ab cdef</value>
            </add-value>
          </modify-attr>
        </modify>
      </input>
    </nds>
    [04/30/21 17:48:39.263]:ADtest ST:No command transformation policies.
    [04/30/21 17:48:39.263]:ADtest ST:Filtering out notification-only attributes.
    [04/30/21 17:48:39.263]:ADtest ST:Fixing up association references.
    [04/30/21 17:48:39.263]:ADtest ST:Applying schema mapping policies to output.
    [04/30/21 17:48:39.263]:ADtest ST:Applying policy: %+C%14CSchemaMap%-C.
    [04/30/21 17:48:39.264]:ADtest ST:  Mapping attr-name 'employeeType' to 'carLicense'.
    [04/30/21 17:48:39.264]:ADtest ST:  Mapping attr-name 'Telephone Number' to 'businessCategory'.
    [04/30/21 17:48:39.264]:ADtest ST:  Mapping class-name 'unigeChUser' to 'user'.
    [04/30/21 17:48:39.264]:ADtest ST:No output transformation policies.
    [04/30/21 17:48:39.264]:ADtest ST:Submitting document to subscriber shim:
    [04/30/21 17:48:39.265]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <modify class-name="user" event-id="idmserver1#20210430154839#3#1:274b639d-bede-4786-ad50-9d634b27debe" from-merge="true" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400">
          <association>d624a9c35a4a4a47a1b30c0a35dba5a2</association>
          <modify-attr attr-name="carLicense">
            <remove-all-values/>
            <add-value>
              <value timestamp="1619795777#15" type="string">ASSISTANT</value>
            </add-value>
          </modify-attr>
          <modify-attr attr-name="businessCategory">
            <remove-all-values/>
            <add-value>
              <value timestamp="1619797641#15" type="teleNumber">+41 22 ab ghij</value>
              <value timestamp="1619797641#16" type="teleNumber">+41 22 ab cdef</value>
            </add-value>
          </modify-attr>
        </modify>
      </input>
    </nds>
    [04/30/21 17:48:39.267]:ADtest ST:Remote Interface Driver: Sending...
    [04/30/21 17:48:39.267]:ADtest ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.7.4.0">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <modify class-name="user" event-id="idmserver1#20210430154839#3#1:274b639d-bede-4786-ad50-9d634b27debe" from-merge="true" qualified-src-dn="C=Ch\O=UniGe\OU=UniGePerson\NSCP:employeeNumber=862455" src-dn="\IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455" src-entry-id="94400">
          <association>d624a9c35a4a4a47a1b30c0a35dba5a2</association>
          <modify-attr attr-name="carLicense">
            <remove-all-values/>
            <add-value>
              <value timestamp="1619795777#15" type="string">ASSISTANT</value>
            </add-value>
          </modify-attr>
          <modify-attr attr-name="businessCategory">
            <remove-all-values/>
            <add-value>
              <value timestamp="1619797641#15" type="teleNumber">+41 22 ab ghij</value>
              <value timestamp="1619797641#16" type="teleNumber">+41 22 ab cdef</value>
            </add-value>
          </modify-attr>
        </modify>
      </input>
    </nds>
    [04/30/21 17:48:39.270]:ADtest ST:Remote Interface Driver: Document sent.
    [04/30/21 17:48:39.270]:ADtest ST:Remote Interface Driver: Waiting for receive...
    [04/30/21 17:48:39.274]:ADtest ST:Remote Interface Driver: Received
    [04/30/21 17:48:39.274]:ADtest ST:
    <nds dtdversion="1.1" ndsversion="8.7">
      <source>
        <product asn1id="" build="20180125_120000" instance="\IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest" version="4.1.0.0">AD</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <output>
        <status event-id="idmserver1#20210430154839#3#1:274b639d-bede-4786-ad50-9d634b27debe" level="success"/>
      </output>
    </nds>
    [04/30/21 17:48:39.275]:ADtest ST:Remote Interface Driver: Received command: SUBSCRIBER REPLY(10).
    [04/30/21 17:48:39.275]:ADtest ST:SubscriptionShim.execute() returned:
    [04/30/21 17:48:39.275]:ADtest ST:
    <nds dtdversion="1.1" ndsversion="8.7">
      <source>
        <product asn1id="" build="20180125_120000" instance="\IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest" version="4.1.0.0">AD</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <output>
        <status event-id="idmserver1#20210430154839#3#1:274b639d-bede-4786-ad50-9d634b27debe" level="success"/>
      </output>
    </nds>
    [04/30/21 17:48:39.276]:ADtest ST:No input transformation policies.
    [04/30/21 17:48:39.276]:ADtest ST:Applying schema mapping policies to input.
    [04/30/21 17:48:39.276]:ADtest ST:Applying policy: %+C%14CSchemaMap%-C.
    [04/30/21 17:48:39.277]:ADtest ST:Resolving association references.
    [04/30/21 17:48:39.279]:ADtest ST:Processing returned document.
    [04/30/21 17:48:39.279]:ADtest ST:Processing operation <status> for .
    [04/30/21 17:48:39.279]:ADtest ST:
    DirXML Log Event -------------------
         Driver:   \IDM-TREE-LAB\Ch\UniGe\Idm\DriverSet\ADtest
         Channel:  Subscriber
         Object:   \IDM-TREE-LAB\Ch\UniGe\UniGePerson\862455
         Status:   Success
    [04/30/21 17:48:39.280]:ADtest ST:End transaction.
    

    Here are the relevant configurations:


    attributeTypes: ( 2.5.4.20 NAME 'telephoneNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{64512} X-NDS_NAME 'Telephone Number' X-NDS_NONREMOVABLE '1' )

    <attr-def asn1id="" attr-name="businessCategory" case-sensitive="false" multi-valued="true" naming="false" read-only="false" required="false" type="string"/>
    <attr-def asn1id="" attr-name="telephoneNumber" case-sensitive="false" multi-valued="false" naming="false" read-only="false" required="false" type="string"/>

    <filter>
    <filter-class class-name="unigeChUser" publisher="ignore" publisher-create-homedir="false" publisher-track-template-member="false" subscriber="sync">
    <filter-attr attr-name="employeeType" merge-authority="edir" publisher="ignore" publisher-optimize-modify="true" subscriber="sync"/>
    <filter-attr attr-name="Telephone Number" merge-authority="edir" publisher="ignore" publisher-optimize-modify="true" subscriber="sync"/>
    </filter-class>
    </filter>

    <attr-name-map>
    <class-name>
    <nds-name>unigeChUser</nds-name>
    <app-name>user</app-name>
    </class-name>
    <attr-name class-name="unigeChUser">
    <nds-name>employeeType</nds-name>
    <app-name>carLicense</app-name>
    </attr-name>
    <attr-name class-name="unigeChUser">
    <nds-name>Telephone Number</nds-name>
    <app-name>businessCategory</app-name>
    </attr-name>
    </attr-name-map>

    It is probably an old bug: the driver where I spotted this problem has been coded long time ago (IDM 3.6 I would believe) and it is because there was "strange" rules copying employeeType from the IDV source that I wondered why it was necessary and thus (re)discovered this issue.

    I am still curious to know if somebody can replicate the problem.

    Regards,
    Dominique