What To Do When NetIQ IDM Delete Event Contains No Association

While recently working with NetIQ IDM 4.02 and NetIQ eDirectory 8.8.7 IR 7, we had an issue arise and wanted to pass along the solution.

When deleting an object which has been verified to have an association, all drivers in a driver set have a delete event generated that does not have an association on it.  This causes events that are triggered by this to not function as designed.

This is a sample of what the delete event looks like for this issue:

<nds dtdversion=”4.0″ ndsversion=”8.x”>

  <source>

    <product edition=”Standard” version=”4.0.2.2″>DirXML</product>

    <contact>Novell, Inc.</contact>

  </source>

  <input>

    <delete cached-time=”20140912181405.314Z” class-name=”User” event-id=”VMIDMMETA#20140912181405#4#5:db434926-90f3-44f0-e1bf-264943dbf390″ qualified-src-dn=”O=IDMOU=PersonOU=UsersCN=DeleteTest” src-dn=”METAIDMPersonUsersDeleteTest” src-entry-id=”117061″ timestamp=”1410545529#1″/>

  </input>

</nds>

In determining the root cause of this problem, we had to examine what the process was for eDirectory during the delete process.  When an object in eDirectory is deleted, it gets set as “Not Present” object and has the majority of its attributes removed, with a few exceptions like Obituary.  This means that IDM cannot be pulling the association value from the DirXML-Associations value on the object itself, since it would no longer be listed there.  This led us to the conclusion that it was either pulling it from the index, or pulling it from eDirectory cache.  Because rebuilding the eDirectory cache would require us to restart eDirectory, we opted to go with the option of dropping the index on DirXML-Association and then rebuilding it. However, after we dropped the index we waited for over an hour for the index to rebuild, and after it still had not rebuilt we ended up stopping eDirectory and then restarting it.  The index finished building within a matter of moments and at this point the delete event properly showed an association on delete.

<nds dtdversion=”4.0″ ndsversion=”8.x”>

  <source>

    <product edition=”Standard” version=”4.0.2.2″>DirXML</product>

    <contact>Novell, Inc.</contact>

  </source>

  <input>

    <delete cached-time=”20140916151028.321Z” class-name=”User” event-id=”VMIDMMETA#20140916151028#4#1:63190e11-ad46-49d3-7893-110e196346ad” qualified-src-dn=”O=IDMOU=PersonOU=UsersCN=TestingDelete” src-dn=”METAIDMPersonUsersTestingDelete” src-entry-id=”117161″ timestamp=”1410880116#7″>

      <association state=”associated”>ad44d96c7bc72748b98bcd6f17ac30ed</association>

    </delete>

  </input>

</nds>

From this, we were able to surmise that whether the index was corrupt, or not, that the appropriate step needed to be taken in a situation like this would be to restart eDirectory.

NOTE: It should also be noted that after removing the index for DirXML-Associations that the User Application JBoss Instance crashed, and would not restart until after eDirectory had been loaded.  Also, nobody was able to authenticate to the eDirectory instance on that, even though that shouldn’t be caused by simply removing a single index, especially one for an attribute that has nothing to do with authentication.  This is one of the issues that led us to believe it was an issue with the eDirectory cache.

 

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.