Synchronising structured attribute (ndsHomeDirectory)

Hello,

I would like IDM to take control of the value of attribute ndsHomeDirectory on the connected system (eDirectory).
IDM creates home directories on the connected system via another driver, therefore it should also synchronise the corresponding attributes over bidirectional driver.
The synchronisation of homeDirectory attribute works, but synchronisation of ndsHomeDirectory doesnt.

It is not possible to have a structured attribute (same as ndsHomeDirectory) on IDM because the volume path does not exist on IDM.
Instead I created a new attribute on IDM named IDM_ndsHomeDirectory, which is a case ignore string.
This string attribute is then reformated to a structured attribute in otp.

The document submitted to subscriber shim looks like shown below. Side note: the association-ref and type XML attributes were hardcoded for testing purpuses.

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Standard" version="4.9.0.0000">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input>
    <modify class-name="inetOrgPerson" event-id="dz-idm-01#20250116133950#1#1:8297e303-b7f9-4404-9fce-03e39782f9b7" from-merge="true" qualified-src-dn="\xxx\CN=test" src-dn="\xxx\test" src-entry-id="64443">
    <association>AAAC4D92D7C261439025AAAC4D92D7C2</association>
	<modify-attr attr-name="homeDirectory">
        <remove-all-values/>
        <add-value>
          <value timestamp="1724410149#7" type="string">/home/test</value>
        </add-value>
    </modify-attr>
	<modify-attr attr-name="ndsHomeDirectory">
        <remove-all-values/>
        <add-value>
          <value type="structured">
            <component name="nameSpace">0</component>
            <component association-ref="9D37F68B34A68C4DB7F19D37F68B34A6" name="volume" type="dn">cn=vol1-server_VOL1,ou=OESSystemObjects,xxx</component>
            <component name="path">USERS\test</component>
          </value>
        </add-value>
      </modify-attr>
    </modify>
  </input>
</nds>

The problem is that this modification succeeds but there is no change of the ndsHomeDirectory attribute on the connected system.
The trace below starts right after submitting to subscriber shim. You can see that the event results in success but there is no value in the ldap modification.

[01/16/25 14:47:46.803]:eDir2eDir ST:eDir2eDir: LDAP Search
  base=xxx
  scope=2
  filter=guid=\9D\37\F6\8B\34\A6\8C\4D\B7\F1\9D\37\F6\8B\34\A6
  attrs=[dn]
  attrsOnly=false
[01/16/25 14:47:46.912]:eDir2eDir ST:eDir2eDir: LDAP Modify: cn=test,xxx
  LDAPModification: (operation=replace,(LDAPAttribute: {type='homeDirectory', value='/home/test'}))
  LDAPModification: (operation=replace,(LDAPAttribute: {type='ndsHomeDirectory'}))
[01/16/25 14:47:46.919]:eDir2eDir ST:SubscriptionShim.execute() returned:
[01/16/25 14:47:46.919]:eDir2eDir ST:
<nds dtdversion="2.0" ndsversion="8.x">
  <source>
    <product build="20240201_1039" instance="eDir2eDir" version="4.1.0.0000">Identity Manager Bi-directional Driver for eDirectory</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <output>
    <status event-id="dz-idm-01#20250116134745#1#1:42f857de-272b-4f51-bef3-de57f8422b27" level="success"/>
  </output>
</nds>

At first I thought it was an issue with association-ref but hard-coding it in the event as shown above did not help.

I have also traced the event on the connected system using ndstrace, where the ldap modification of the ndsHomeDirectory attribute succeeds.
I was not able to see the value of the modification in ndstrace. Is it possible to see the value there?

Does anyone have experience at synchronising structured attributes? Thanks in advance! 

  • Verified Answer

    +1

    It turns out the solution is not to do any reformating in otp. Simply submit the string value to the shim, for example:

    [01/21/25 14:16:52.447]:eDir2eDir ST:Submitting document to subscriber shim:
    [01/21/25 14:16:52.447]:eDir2eDir ST:
    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product edition="Standard" version="4.9.0.0000">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <modify cached-time="20250121131652.330Z" class-name="inetOrgPerson" src-dn="\xxx\test" .........>
          <association state="associated">AAAC4D92D7C261439025AAAC4D92D7C2</association>
          <modify-attr attr-name="ndsHomeDirectory">
            <remove-all-values/>
            <add-value>
              <value timestamp="1737465412#2" type="string">cn=vol1-server_VOL1,ou=OESSystemObjects,xxx#0#USERS\test2</value>
            </add-value>
          </modify-attr>
        </modify>
      </input>
    </nds>
    [01/21/25 14:16:52.448]:eDir2eDir ST:eDir2eDir: Making the GUID Cache capcity as 10000.
    [01/21/25 14:16:52.448]:eDir2eDir ST:eDir2eDir: LDAP Search
      base=xxx
      scope=2
      filter=guid=\AA\AC\4D\92\D7\C2\61\43\90\25\AA\AC\4D\92\D7\C2
      attrs=[dn]
      attrsOnly=false
    [01/21/25 14:16:52.450]:eDir2eDir ST:eDir2eDir: LDAP Modify: cn=test,xxx
      LDAPModification: (operation=add,(LDAPAttribute: {type='ndsHomeDirectory', value='cn=vol1-server_VOL1,ou=OESSystemObjects,xxx#0#USERS\test'}))
    [01/21/25 14:16:52.453]:eDir2eDir ST:SubscriptionShim.execute() returned:
    [01/21/25 14:16:52.453]:eDir2eDir ST:
    <nds dtdversion="2.0" ndsversion="8.x">
      <source>
        <product build="20240201_1039" instance="eDir2eDir" version="4.1.0.0000">Identity Manager Bi-directional Driver for eDirectory</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <output>
        <status event-id="dz-idm-01#20250121131652#1#1:92efac15-80a9-4067-a6ab-15acef92a980" level="success"/>
      </output>
    </nds>

    Interestingly, the attribute comes in as a structured attribute on the publisher channel which led me down this rabbit hole in the first place... So reformating needs to be done in itp.

    Best regards, Nik

  • 0  

    I will be if you look in the engine trace you will see a message about cannot resolve reference to either the DN of the volume object i the ndsHomeDir or the Association reference.  This happens after the Command Transform, before the OTP. So the value is removed, and thus as you see in the driver side trace, the LDAP modify is replace for ndsHomeDirectory with no value.

    You issue is you need to sync the DN reference, not as a DN.  You could for example, try something immensely stupid like this to change the TYPE of the volume component from 'dn' to 'string'.  WHich makes no sense, but the engine will honour it.

    <do-set-xml-attr expression='modify-attr[@attr-name="ndsHomeDirectory"]/add-value/value/component[@name="volume"]' name="type">
    	<arg-string>
    		<token-text xml:space="preserve">string</token-text>
    	</arg-string>
    </do-set-xml-attr>

    Using Simulator that looks like it works:

    <nds dtdversion="4.0" ndsversion="8.x">
      <source>
        <product version="4.9.0.0000">DirXML</product>
        <contact>NetIQ Corporation</contact>
      </source>
      <input>
        <modify class-name="inetOrgPerson" event-id="dz-idm-01#20250116133950#1#1:8297e303-b7f9-4404-9fce-03e39782f9b7" from-merge="true" qualified-src-dn="\xxx\CN=test" src-dn="\xxx\test" src-entry-id="64443">
          <association>AAAC4D92D7C261439025AAAC4D92D7C2</association>
          <modify-attr attr-name="homeDirectory">
            <remove-all-values/>
            <add-value>
              <value timestamp="1724410149#7" type="string">/home/test</value>
            </add-value>
          </modify-attr>
          <modify-attr attr-name="ndsHomeDirectory">
            <remove-all-values/>
            <add-value>
              <value type="structured">
                <component name="nameSpace">0</component>
                <component association-ref="9D37F68B34A68C4DB7F19D37F68B34A6" name="volume" type="string">cn=vol1-server_VOL1,ou=OESSystemObjects,xxx</component>
                <component name="path">USERS\test</component>
              </value>
            </add-value>
          </modify-attr>
        </modify>
      </input>
    </nds>

    Then it should get through the eDir-eDir driver and you can transform it on the other side to whatever makes sense for storing this info.

  • 0 in reply to   

    I tried your suggestion out of curiosity and with intention to take control over data transformation instead of letting (I guess) the shim do the conversion.

    Sadly, changing the type to string does not work. The result is same as original (pasted in the first post).

  • 0   in reply to 

    Hmm, I would like to see trace of that. I am pretty sure that should have worked.  Feel free to send offline if you want.  (First name last name at gmail). 

  • 0 in reply to   

    Just checking if you have received my email.

  • 0   in reply to 

    I did, sorry been busy.  Will look at it.