Identity Manager query returns the same user multiple times

If IDM performs a query to eDirectory based on an attribute that has been indexed and one object is supposed to match, the object is returned multiple times. This query can be part of the matching rule or by using a token-query noun.

For example, a query like this one:

<query class-name="User" scope="subtree">
<search-class class-name="User"/>
<search-attr attr-name="workforceID">
<value>12345</value>
</search-attr>
<read-attr/>

will result, if there is no index for the workforceID attribute, in only one result:
<instance class-name="User" qualified-src-dn="O=novell\CN=test"
src-dn="\EDIR\novell\test" src-entry-id="32954">
<association state="manual"></association>
</instance>

But if there is an index for the attribute and the index was created with eDirectory versions  8.8.6.2 or 8.8.5.6, this operation results in the same entry being returned multiple times:

<output>
<instance class-name="User" qualified-src-dn="O=novell\CN=test"
src-dn="\EDIR\novell\test" src-entry-id="32954">
<association state="manual"></association>
</instance>
<instance class-name="User" qualified-src-dn="O=novell\CN=test"
src-dn="\EDIR\novell\test" src-entry-id="32954">
<association state="manual"></association>
</instance>
<instance class-name="User" qualified-src-dn="O=novell\CN=test"
src-dn="\EDIR\novell\test" src-entry-id="32954">
<association state="manual"></association>
</instance>
<status level="success"></status>

The problem can occur in two types of queries:
 1 - A sub-tree search where no context has been specified.
 2 - A search for "subordinates", also known as a one level search.

As mentioned above, this issue will occur only if the query that is being performed uses an index that has been created with eDirectory versions 8.8.5.6 or 8.8.6.2. The reason for this is that these versions will include information about the AncestorsID in the index itself. This feature is turned off by default from version 8.8.6.3 onwards.

The issue has been reported to engineering, a permanent fix is not available at the moment. There are two ways to work-around the issue:
 1 - Modify the query to avoid the problem condition. In the case of a sub-tree search, specify a base container for the search. In the case of a "subordinates" query, if logic and tree structure allows, change it to a sub-tree search.
 2 - If the index has been created with eDirectory 8.8.5.6 or 8.8.6.2, upgrade eDirectory to 8.8.6.3, delete the index that the query is using and then create it again. By creating it with 8.8.6.3, the AncestorsID will not be added automatically.

The problem should not occur if the query is performed using an index that has been created with an older version of eDirectory, even if the query is done against a server running eDirectory 8.8.5.6 or 8.8.6.2.