Single AD query is returning both a success and error at the same time

[wferguson]

From the eDirectory side...I initiated a migrate to Active Directory on an account that didn't have an AD association. The migrate was turned into a Synthetic Add, then when going through the matching polices and querying AD....I know the account exists in AD and the matching attributes are there as well but the return results of the query #1 are as follows and it looks like it is reporting that it found the match but the it also tried to create.....hence the reason for the status of success and then status of error 'ldap already exist'. Can someone please help me make sense of this ?

<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.7.2.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="user" dest-dn="DC=xxx,DC=xxx,DC=xxx" event-id="0" scope="subtree">
<search-class class-name="user"/>
<search-attr attr-name="sAMAccountName">
<value type="string">Chocolate</value>
</search-attr>
<search-attr attr-name="businessCategory">
<value timestamp="1574868858#240" type="string">EID0028</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>
[12/03/19 15:35:02.308]:HIMCG ST: Remote Interface Driver: Document sent.
[12/03/19 15:35:02.308]:HIMCG ST: Remote Interface Driver: Received
[12/03/19 15:35:02.308]:HIMCG ST:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20180125_120000" instance="\IDV\AD_xxx" version="4.1.0.0">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status event-id="ent-prodidm-idv01#20191203203428#1#2:6434-4d5b-9a47-ed84ec9b3464" level="success"/>
<status event-id="ent-prodidm-idv01#20191203203428#1#2:6434-4d5b-9a47-ed84ec9b3464" level="error" type="driver-general">
<ldap-err ldap-rc="68" ldap-rc-name="LDAP_ALREADY_EXISTS">
<client-err ldap-rc="68" ldap-rc-name="LDAP_ALREADY_EXISTS">Already Exists</client-err>
<server-err>00000562: UpdErr: DSID-031A11D7, problem 6005 (ENTRY_EXISTS), data 0
</server-err>
<server-err-ex win32-rc="1378"/>
</ldap-err>
</status>
</output>
</nds>
[12/03/1

[al_b]

What trace level you have on RemoteLoader side?

1. I can recommend setting of RemoteLoader trace to level 5 or at least 3.

2. Publish RemoteLoader trace for this query operation.

It supposed to include details about the query to AD and the exact response from AD.

[Michiel Los]

In your search there is one strange thing, a timestamp on the value, normally this is never on a search attribute. Might be a problem there.

[wferguson]

Could you please explain the significance of a timestamp being on a query object ?

[wferguson]

Attached is the driver trace up until the errors and my apologies as I do not have the remote loader trace and I am unable to reproduce the error on this particular account since I have moved the account manually and now it syncs fine. 

3 questions I have:

1)Why did the first match rule return a success and error both?

<status event-id="ent-prodidm-idv01#20191203203428#1#2:6434-4d5b-9a47-ed84ec9b3464" level="success"/>
<status event-id="ent-prodidm-idv01#20191203203428#1#2:6434-4d5b-9a47-ed84ec9b3464" level="error" type="driver-general">

2)Why does it appear that all of the query 'results' from AD are always one rule behind? Meaning it seems when a query is done on Full Name for example, the driver returns fail...but the next query that is done in a following rule for a different attribute.....will return the value of the Full Name attribute even though the current query did not even query for it but instead the previous query was looking for Full Name. I am seeing that on most every query to AD.

3)Code(-9999) Element &lt;parent> does not have a valid association ? I am thinking this is because the account was moving and the association still had the old location in it. 

[al_b]

It is better to look directly into RemoteLoader trace (what kind of query going to AD and what AD returned).

From Engine perspective, driver initiate query with search based on 2 attributes.

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product edition="Advanced" version="4.7.2.0">xmldir</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input>
    <query class-name="User" dest-dn="DC=medical,DC=educational" scope="subtree">
      <search-class class-name="User"/>
      <search-attr attr-name="CN">
        <value type="string">BUBBAGUMP</value>
      </search-attr>
      <search-attr attr-name="uniqueID">
        <value timestamp="1574868858#240" type="string">7584393EID</value>
      </search-attr>
      <read-attr/>
    </query>
  </input>
</nds>

 Please provide RemoteLoader trace

[wferguson]

Yes the matching rule is looking for two attributes and so I am guessing the return status is one for each attribute? I was not aware that it returns a status for each attribute but rather it would be a success for finding a matching account based on the 2 attributes being found or either a status of failure if one or neither attribute was found.

If that is the case....why on the second rule when the match was found does it just have a simple success and not a success for each of the two attributes it searched for.

Any thoughts on the other 2 questions?

[al_b]

This is a reason, why we have to look into RemoteLoader log.
How this IDM query "transformed" to AD (LDAP) query and what kind of result AD return?
>other 2 questions
Let's solve problems sequentially. First things first...
Maybe answer for the first question will provide answer to the second question too

[wferguson]

my apologies as I do not have the remote loader trace and I am unable to reproduce the error on this particular account since I have moved the account manually and now it syncs fine.

[al_b]

The move is always a "questionable" operation for almost any LDAP implementation.

The server can have an "incomplete" double copy of the object before "internal" cut off.

In theory "move" on AD end can generate a "double" response.

I can recommend enabling RemoteLoader trace (at least for level 3).

It will help you in your future troubleshooting and show things specific for application (in this case AD), that not available in the Engine side trace.

[al_b · Accepted solution]

I expect to see filter generated by driver SHIM and expect to see AND filter
something like (&(cn=user1)(uid=user1)) that will return one result instead 2 separate query.
This info will be available only in RL trace