ALERT! The community will be read-only on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only on April 19, 8am Pacific as the migration begins.Read more for important details.
Lieutenant Commander
Lieutenant Commander
440 views

AD driver object match returning success but showing No matches found

Jump to solution

Trying to setup an Active directory driver using remote loader on a domain server to replace / upgrade a current driver.

I can see the query sent to the remote loader and the remote loader processes the query with success and returned it back to the driver. The driver comes back with match not found error.

Any help would be appreciated

Thanks

Dan

 

DirXML: [04/07/21 13:18:12.98]: Loader: XML Document:
DirXML: [04/07/21 13:18:12.98]: <nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="user" dest-dn="dc=XXXX,dc=org" event-id="0" scope="subtree">
<search-class class-name="user"/>
<search-attr attr-name="displayName">
<value type="string">Angela Dowdle</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>
DirXML: [04/07/21 13:18:12.98]: ADDriver: parse command

className user
destDN dc=XXXX,dc=org
eventId 0
association
DirXML: [04/07/21 13:18:12.98]: ADDriver: query
DirXML: [04/07/21 13:18:12.98]: ADDriver: query constraints
DirXML: [04/07/21 13:18:12.98]: ADDriver: search-class user
DirXML: [04/07/21 13:18:12.98]: ADDriver: search-attr displayName
DirXML: [04/07/21 13:18:12.98]: ADDriver: Angela Dowdle
DirXML: [04/07/21 13:18:12.98]: ADDriver: read-attr (do not return attributes)
DirXML: [04/07/21 13:18:12.98]: ADDriver: Connect using ldap_bind: user=adminuser, domain=XXXX, password=***,
method=negotiate, server=x.x.x.x, sign=no, seal=no ssl=no
DirXML: [04/07/21 13:18:12.98]: ADDriver: ldap_bind connection succeeded


DirXML: [04/07/21 13:18:12.98]: ADDriver: query
base DN: dc=XXXX,dc=org,
filter: (&(&(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=XXXX,DC=org)(objectClass=user))(displayName=Angela Dowdle)),
return: (attribute values) objectClass, objectGUID,
DirXML: [04/07/21 13:18:12.98]: ADDriver: query
base DN: dc=XXXX,dc=org,
filter: (&(&(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=XXXX,DC=org)(objectClass=user))(displayName=Angela Dowdle)),
return: (attribute values) objectClass, objectGUID,
DirXML: [04/07/21 13:18:12.98]: ADDriver: ldap get next page ( 2147483647)
DirXML: [04/07/21 13:18:12.98]: ADDriver: ldap get next page ( 2147483647)
DirXML: [04/07/21 13:18:12.98]: Loader: subscriptionShim->execute() returned:
DirXML: [04/07/21 13:18:12.98]: Loader: XML Document:

DirXML: [04/07/21 13:18:12.98]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="4.0.0.4" asn1id="" build="20140409_120000" instance="\VAULT\Organazation\idm\IDM_Vault\Vaut2AD">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<instance src-dn="CN=Angela Dowdle,OU=Faculty,OU=sub,OU=Other,DC=XXXX,DC=org" class-name="user" event-id="0">
<association>73dda42b4f84614fa2e5fa2bc364968f</association>
</instance>
<status level="success" event-id="0"/>
</output>
</nds>

DirXML: [04/07/21 13:18:12.98]:
DirXML Log Event -------------------
Driver = \VAULT\Organazation\idm\IDM_Vault\Vaut2AD
Thread = Subscriber Channel
Level = success
DirXML: [04/07/21 13:18:13.23]: Loader: Received 'subscriber execute' document

I see the response in the driver log

[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Query from policy
[04/07/21 15:40:46.174]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="User" dest-dn="dc=XXXX,dc=org" scope="subtree">
<search-class class-name="User"/>
<search-attr attr-name="displayName">
<value type="string">Angela Dowdle</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>
[04/07/21 15:40:46.182]:Vaut2ADDriver ST: Fixing up association references.

----

04/07/21 15:40:46.287]:Vaut2ADDriver ST: Remote Interface Driver: Document sent.
[04/07/21 15:40:46.297]:Vaut2ADDriver :Remote Interface Driver: Received.
[04/07/21 15:40:46.297]:Vaut2ADDriver :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20140409_120000" instance="\VAULT\Organazation\idm\IDM_Vault\Vaut2AD" version="4.0.0.4">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<instance class-name="user" event-id="0" src-dn="CN=Angela Dowdle,OU=Faculty,OU=sub,OU=Other,DC=XXXX,DC=org">
<association>73dda42b4f84614fa2e5fa2bc364968f</association>
</instance>
<status event-id="0" level="success"/>
</output>
</nds>
[04/07/21 15:40:46.298]:Vaut2ADDriver :Remote Interface Driver: Received document for subscriber channel

---

[04/07/21 15:40:46.491]:Vaut2ADDriver ST: No matches found.

 

[04/07/21 15:40:46.491]:Vaut2ADDriver ST: Action: do-status(level="success","error.do-find.matchng-object = *"+token-op-attr("$error.do-find-matching-object$")+"*"+token-char(value="10")+"success.do-find-matching-object = *"+token-op-attr("$success.do-find-matching-object$")+"*"+token-char(value="10")+"src-dn = "+token-src-dn()+token-src-dn()+token-char(value="10")+"dest-dn = "+token-dest-dn()).
[04/07/21 15:40:46.492]:Vaut2ADDriver ST: arg-string("error.do-find.matchng-object = *"+token-op-attr("$error.do-find-matching-object$")+"*"+token-char(value="10")+"success.do-find-matching-object = *"+token-op-attr("$success.do-find-matching-object$")+"*"+token-char(value="10")+"src-dn = "+token-src-dn()+token-src-dn()+token-char(value="10")+"dest-dn = "+token-dest-dn())
[04/07/21 15:40:46.492]:Vaut2ADDriver ST: token-text("error.do-find.matchng-object = *")
[04/07/21 15:40:46.492]:Vaut2ADDriver ST: token-op-attr("$error.do-find-matching-object$")
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: Expanded variable reference '$error.do-find-matching-object$' to ''.
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: Token Value: "".
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: token-text("*")
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: token-char(value="10")
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: Token Value: "
".
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: token-text("success.do-find-matching-object = *")
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: token-op-attr("$success.do-find-matching-object$")
[04/07/21 15:40:46.493]:Vaut2ADDriver ST: Expanded variable reference '$success.do-find-matching-object$' to ''.
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: Token Value: "".
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: token-text("*")
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: token-char(value="10")
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: Token Value: "
".
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: token-text("src-dn = ")
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: token-src-dn()
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: Token Value: "\VAULT\Organazation\Company\Sub\Faculty\Angela-Dowdle".
[04/07/21 15:40:46.494]:Vaut2ADDriver ST: token-src-dn()
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: Token Value: "\VAULT\Organazation\Company\Sub\Faculty\Angela-Dowdle".
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: token-char(value="10")
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: Token Value: "
".
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: token-text("dest-dn = ")
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: token-dest-dn()
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: Token Value: "".
[04/07/21 15:40:46.495]:Vaut2ADDriver ST: Arg Value: "error.do-find.matchng-object = **
success.do-find-matching-object = **
src-dn = \VAULT\Organazation\Company\Sub\Faculty\Angela-Dowdle\VAULT\Organazation\Company\Sub\Faculty\Angela-Dowdle
dest-dn = ".
[04/07/21 15:40:46.496]:Vaut2ADDriver ST:
DirXML Log Event -------------------

----

 

0 Likes
1 Solution

Accepted Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

Ok, looks like you have in your policies a mix of query directions.


Matching policy query AD for find correspondent AD object.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: (if-src-attr 'Full Name' available) = TRUE.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: Rule selected.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: Applying rule 'Match_0n_Full-Name_to_DisplayName'.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: Action: do-find-matching-object(scope="subtree",arg-dn(token-global-variable("drv.user.container")),arg-match-attr("displayName",token-dest-attr("displayName",class-name="User")+token-src-attr("Full Name",class-name="User"))).
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: arg-dn(token-global-variable("drv.user.container"))
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: token-global-variable("drv.user.container")
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: Token Value: "dc=XXXX,dc=org".
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: Arg Value: "dc=XXXX,dc=org".
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: arg-match-attr("displayName",token-dest-attr("displayName",class-name="User")+token-src-attr("Full Name",class-name="User"))
[04/07/21 15:40:46.172]:Vaut2ADDriver ST: arg-string(token-dest-attr("displayName",class-name="User")+token-src-attr("Full Name",class-name="User"))
[04/07/21 15:40:46.172]:Vaut2ADDriver ST: token-dest-attr("displayName",class-name="User")
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Token Value: "".
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: token-src-attr("Full Name",class-name="User")
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Token Value: "Angela Dowdle".
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Arg Value: "Angela Dowdle".
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Query from policy
[04/07/21 15:40:46.174]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="User" dest-dn="dc=XXXX,dc=org" scope="subtree">
<search-class class-name="User"/>
<search-attr attr-name="displayName">
<value type="string">Angela Dowdle</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>

AD object found:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20140409_120000" instance="\VAULT\Organazation\idm\IDM_Vault\Vaut2AD" version="4.0.0.4">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<instance class-name="user" event-id="0" src-dn="CN=Angela Dowdle,OU=Faculty,OU=sub,OU=Other,DC=XXXX,DC=org">
<association>73dda42b4f84614fa2e5fa2bc364968f</association>
</instance>
<status event-id="0" level="success"/>
</output>
</nds>

Pub-ITP-Driver-Veto policy in Input Transformation receive this result and initiate another query to eDirectory (?):
[04/07/21 15:40:46.452]:Vaut2ADDriver ST: Applying policy: %+C%14CPub-ITP-Driver-Veto%-C.
[04/07/21 15:40:46.452]:Vaut2ADDriver ST: Applying to instance #1.
[04/07/21 15:40:46.453]:Vaut2ADDriver ST: Evaluating selection criteria for rule 'Driver-Veto-Testing'.
[04/07/21 15:40:46.453]:Vaut2ADDriver ST: (if-class-name equal "User") = TRUE.
[04/07/21 15:40:46.453]:Vaut2ADDriver ST: Query from policy
[04/07/21 15:40:46.453]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="user" scope="entry">
<association>73dda42b4f84614fa2e5fa2bc364968f</association>
<read-attr attr-name="roomNumber"/>
</query>
</input>
</nds>

Association to this AD object not exist in eDirectory yet:
[04/07/21 15:40:46.454]:Vaut2ADDriver ST: Pumping XDS to eDirectory.
[04/07/21 15:40:46.454]:Vaut2ADDriver ST: Performing operation query for .
[04/07/21 15:40:46.479]:Vaut2ADDriver ST: Query from policy result
[04/07/21 15:40:46.479]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status level="error">Code(-9039) Element &lt;query> does not have a valid association.</status>
</output>
</nds>

The result of your custom (unnecessary) query from Pub-ITP-Driver-Veto overrides original matching results to an empty document.
The matching policy never get results

[04/07/21 15:40:46.490]:Vaut2ADDriver ST: Resolving association references.
[04/07/21 15:40:46.491]:Vaut2ADDriver ST: Query from policy result
[04/07/21 15:40:46.491]:Vaut2ADDriver ST:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20140409_120000" instance="\VAULT\Organazation\idm\IDM_Vault\Vaut2AD" version="4.0.0.4">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status event-id="0" level="success"/>
</output>
</nds>
[04/07/21 15:40:46.491]:Vaut2ADDriver ST: No matches found.



The issue in your custom (strange) policy Pub-ITP-Driver-Veto.

View solution in original post

11 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner
Hi Dan,
It will be better if you can provide a "full" trace (from the moment when the driver doing query from matching policy until placement policy).

One of the potential issues that can be in your case: user object, that found in AD according to your matching creteria (<search-attr attr-name="displayName">
<value type="string">Angela Dowdle</value>) already associated with another eDir user.

Full trace can provide more information.
Lieutenant Commander
Lieutenant Commander

Thanks for your input

I did not think that 2 AD drivers accessing the same Active Directory would be the Issue.

I'm upgrading an older 4.0.2 IDM engine with a 4.5 IDM engine with new servers and using the same driver set / eDirectory.

Once I get this driver moved I can remove the old system and can upgrade eDirectory and the IDM engine to the latest version.

So I have two drivers connected with a Vault based trigger (roomNumber = test) isolate the traffic to the between the drivers until testing is done. The new driver has added new users added to the Vault

To test your direction can I remove the Vault users attributes related to the old driver or/and shut down (not not remove the old driver)?

Do you think I need to remove the old driver to test properly?

I have enclosed the remote loader trace, new Driver trace, Match policy XML file and LDAP screen shot of the user's dirxml attributes.

If any more data or testing results helps let me know

Thanks for your help

Dan

 

<?xml version="1.0" encoding="UTF-8"?><policy xmlns:jstring="http://www.novell.com/nxsl/java/java.lang.String">
<description>Find matching object in Active Directory</description>
<rule>
<description>veto out-of-scope events</description>
<comment>When scoping by container, events outside of the Identity Vault containers defined in the above rule will not have a unmatched-src-dn operational property and will be vetoed. If you do not want to use container based scoping, this rule should be modified or removed.</comment>
<conditions>
<or>
<if-op-property name="attempt-to-match" op="not-available"/>
<if-op-property mode="nocase" name="attempt-to-match" op="equal">false</if-op-property>
</or>
</conditions>
<actions>
<do-veto/>
</actions>
</rule>
<rule>
<description>generate full name if not in Identity Vault</description>
<comment xml:space="preserve">Full name policy: Generate a Full Name from Given Name + Surname if one does not already exist. The value is set in the Identity Vault and in the current operation to Active Directory. This policy assumes that Full Name synchronization is enabled in the subscriber filter. If you disable Full Name in the subscriber filter you should not use Full Name mapping.</comment>
<conditions>
<and>
<if-class-name mode="case" op="equal">User</if-class-name>
<if-global-variable mode="nocase" name="FullNameMap" op="equal">true</if-global-variable>
<if-attr name="Full Name" op="not-available"/>
<if-attr name="Given Name" op="available"/>
</and>
</conditions>
<actions>
<do-set-local-variable name="gen-full-name">
<arg-string>
<token-attr name="Given Name"/>
<token-text xml:space="preserve"> </token-text>
<token-attr name="Surname"/>
</arg-string>
</do-set-local-variable>
<do-set-src-attr-value name="Full Name">
<arg-value>
<token-xpath expression="normalize-space($gen-full-name)"/>
</arg-value>
</do-set-src-attr-value>
<do-set-dest-attr-value name="Full Name">
<arg-value>
<token-xpath expression="normalize-space($gen-full-name)"/>
</arg-value>
</do-set-dest-attr-value>
</actions>
</rule>
<rule>
<description>Match_0n_Full-Name_to_DisplayName</description>
<comment xml:space="preserve">Match using the Vault Full Name against the XXXX Display Name </comment>
<conditions>
<and>
<if-class-name mode="nocase" op="equal">User</if-class-name>
<if-src-attr class-name="User" name="Full Name" op="available"/>
</and>
</conditions>
<actions>
<do-find-matching-object scope="subtree">
<arg-dn>
<token-global-variable name="drv.user.container"/>
</arg-dn>
<arg-match-attr name="displayName">
<arg-value type="string">
<token-dest-attr class-name="User" name="displayName"/>
<token-src-attr class-name="User" name="Full Name"/>
</arg-value>
</arg-match-attr>
</do-find-matching-object>
<do-status level="success">
<arg-string>
<token-text xml:space="preserve">error.do-find.matchng-object = *</token-text>
<token-op-attr name="$error.do-find-matching-object$"/>
<token-text xml:space="preserve">*</token-text>
<token-char value="10"/>
<token-text xml:space="preserve">success.do-find-matching-object = *</token-text>
<token-op-attr name="$success.do-find-matching-object$"/>
<token-text notrace="true" xml:space="preserve">*</token-text>
<token-char value="10"/>
<token-text xml:space="preserve">src-dn = </token-text>
<token-src-dn/>
<token-char value="10"/>
<token-text xml:space="preserve">dest-dn = </token-text>
<token-dest-dn/>
</arg-string>
</do-status>
</actions>
</rule>
<rule>
<description>match users based on NT logon name</description>
<comment xml:space="preserve">Logon name policy: Match object name from the Identity Vault to the NT logon name in Active Directory. Because sAMAccountName (CN) is unique in the domain, objects are matched anywhere in the destination hierarchy, not just the relative position in the hierarchy.</comment>
<conditions>
<and>
<if-class-name mode="case" op="equal">User</if-class-name>
<if-global-variable mode="nocase" name="LogonNameMap" op="equal">true</if-global-variable>
</and>
</conditions>
<actions>
<do-find-matching-object scope="subtree">
<arg-dn>
<token-global-variable name="drv.user.container"/>
</arg-dn>
<arg-match-attr name="CN">
<arg-value type="string">
<token-replace-all regex="^a-zA-Z0-9\x21\x23-\x29\x2d\x2e\x40\x5e-\x60\x7b\x7d\x7e\xc0-\xf6\xf8-\xff\x410-\x44f" replace-with="">
<token-src-name/>
</token-replace-all>
</arg-value>
</arg-match-attr>
</do-find-matching-object>
</actions>
</rule>
<rule>
<description>High School match users based on full name</description>
<comment xml:space="preserve">Full name policy: Match user objects in Active Directory whose object name matches the Identity Vault Full Name. Because objects names are only unique within a container, this rule only looks for objects in the same relative position in the hierarchy. This match is not performed if a matching object was found in a previous rule.</comment>
<conditions>
<and>
<if-class-name mode="case" op="equal">User</if-class-name>
<if-global-variable mode="nocase" name="FullNameMap" op="equal">true</if-global-variable>
<if-op-attr name="Full Name" op="available"/>
</and>
</conditions>
<actions>
<do-set-local-variable name="lvp_SourceSchool">
<arg-string>
<token-parse-dn dest-dn-format="qualified-slash" length="4">
<token-src-dn/>
</token-parse-dn>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="lvp_SchoolType">
<arg-string>
<token-src-attr class-name="Organizational Unit" name="L">
<arg-dn>
<token-local-variable name="lvp_SourceSchool"/>
</arg-dn>
</token-src-attr>
</arg-string>
</do-set-local-variable>
<do-status level="success">
<arg-string>
<token-local-variable name="lvp_SchoolType"/>
</arg-string>
</do-status>
<do-find-matching-object scope="entry">
<arg-dn>
<token-op-property name="unmatched-src-dn"/>
<token-text xml:space="preserve">,</token-text>
<token-text xml:space="preserve">ou=</token-text>
<token-local-variable name="lvp_SchoolType"/>
<token-text xml:space="preserve">,</token-text>
<token-text xml:space="preserve">dc=XXXX,dc=org</token-text>
</arg-dn>
<arg-match-attr name="displayName"/>
<arg-match-attr name="CN"/>
</do-find-matching-object>
</actions>
</rule>
<rule disabled="true" notrace="true">
<description>match users based on full name</description>
<comment xml:space="preserve">Full name policy: Match user objects in Active Directory whose object name matches the Identity Vault Full Name. Because objects names are only unique within a container, this rule only looks for objects in the same relative position in the hierarchy. This match is not performed if a matching object was found in a previous rule.</comment>
<conditions>
<and>
<if-class-name mode="case" op="equal">User</if-class-name>
<if-global-variable mode="nocase" name="FullNameMap" op="equal">true</if-global-variable>
<if-op-attr name="Full Name" op="available"/>
</and>
</conditions>
<actions>
<do-if>
<arg-conditions>
<and>
<if-global-variable mode="nocase" name="drv.subPlacementType" op="equal">flat</if-global-variable>
</and>
</arg-conditions>
<arg-actions>
<do-find-matching-object scope="entry">
<arg-dn>
<token-text xml:space="preserve">CN=</token-text>
<token-escape-for-dest-dn>
<token-attr name="Full Name"/>
</token-escape-for-dest-dn>
<token-text>,</token-text>
<token-global-variable name="drv.user.container"/>
</arg-dn>
</do-find-matching-object>
</arg-actions>
<arg-actions>
<do-find-matching-object scope="entry">
<arg-dn>
<token-text xml:space="preserve">CN=</token-text>
<token-escape-for-dest-dn>
<token-attr name="Full Name"/>
</token-escape-for-dest-dn>
<token-text>,</token-text>
<token-replace-first regex="(.+)" replace-with="$1,">
<token-parse-dn length="-2" src-dn-format="dest-dn">
<token-op-property name="unmatched-src-dn"/>
</token-parse-dn>
</token-replace-first>
<token-global-variable name="drv.user.container"/>
</arg-dn>
</do-find-matching-object>
</arg-actions>
</do-if>
</actions>
</rule>
<rule disabled="true" notrace="true">
<description>match everything else</description>
<comment xml:space="preserve">Match objects in Active Directory based on the object name and relative position in the hierarchy.</comment>
<conditions>
<and/>
</conditions>
<actions>
<do-if>
<arg-conditions>
<and>
<if-global-variable mode="nocase" name="drv.subPlacementType" op="equal">flat</if-global-variable>
</and>
</arg-conditions>
<arg-actions>
<do-find-matching-object scope="entry">
<arg-dn>
<token-src-dn convert="true" length="1" start="-1"/>
<token-text xml:space="preserve">,</token-text>
<token-global-variable name="drv.user.container"/>
</arg-dn>
</do-find-matching-object>
</arg-actions>
<arg-actions>
<do-find-matching-object scope="entry">
<arg-dn>
<token-op-property name="unmatched-src-dn"/>
<token-text xml:space="preserve">,</token-text>
<token-global-variable name="drv.user.container"/>
</arg-dn>
</do-find-matching-object>
</arg-actions>
</do-if>
</actions>
</rule>
</policy>

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Just for clarification: I didn't mean 2 AD drivers.

I already saw the issue, when AD has already associated objects.

For example:

1. In the past you had user1 associated with object user1 in eDirectory.

2. Object in eDir renamed to user1xxx and object in AD still has user1.

3. New object user1 created in eDirectory, matching AD object user1, but not able to create an association, as this AD object already associated.

I will review your logs and maybe it will provide more information

Knowledge Partner Knowledge Partner
Knowledge Partner

Ok, looks like you have in your policies a mix of query directions.


Matching policy query AD for find correspondent AD object.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: (if-src-attr 'Full Name' available) = TRUE.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: Rule selected.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: Applying rule 'Match_0n_Full-Name_to_DisplayName'.
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: Action: do-find-matching-object(scope="subtree",arg-dn(token-global-variable("drv.user.container")),arg-match-attr("displayName",token-dest-attr("displayName",class-name="User")+token-src-attr("Full Name",class-name="User"))).
[04/07/21 15:40:46.165]:Vaut2ADDriver ST: arg-dn(token-global-variable("drv.user.container"))
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: token-global-variable("drv.user.container")
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: Token Value: "dc=XXXX,dc=org".
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: Arg Value: "dc=XXXX,dc=org".
[04/07/21 15:40:46.166]:Vaut2ADDriver ST: arg-match-attr("displayName",token-dest-attr("displayName",class-name="User")+token-src-attr("Full Name",class-name="User"))
[04/07/21 15:40:46.172]:Vaut2ADDriver ST: arg-string(token-dest-attr("displayName",class-name="User")+token-src-attr("Full Name",class-name="User"))
[04/07/21 15:40:46.172]:Vaut2ADDriver ST: token-dest-attr("displayName",class-name="User")
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Token Value: "".
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: token-src-attr("Full Name",class-name="User")
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Token Value: "Angela Dowdle".
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Arg Value: "Angela Dowdle".
[04/07/21 15:40:46.173]:Vaut2ADDriver ST: Query from policy
[04/07/21 15:40:46.174]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="User" dest-dn="dc=XXXX,dc=org" scope="subtree">
<search-class class-name="User"/>
<search-attr attr-name="displayName">
<value type="string">Angela Dowdle</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>

AD object found:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20140409_120000" instance="\VAULT\Organazation\idm\IDM_Vault\Vaut2AD" version="4.0.0.4">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<instance class-name="user" event-id="0" src-dn="CN=Angela Dowdle,OU=Faculty,OU=sub,OU=Other,DC=XXXX,DC=org">
<association>73dda42b4f84614fa2e5fa2bc364968f</association>
</instance>
<status event-id="0" level="success"/>
</output>
</nds>

Pub-ITP-Driver-Veto policy in Input Transformation receive this result and initiate another query to eDirectory (?):
[04/07/21 15:40:46.452]:Vaut2ADDriver ST: Applying policy: %+C%14CPub-ITP-Driver-Veto%-C.
[04/07/21 15:40:46.452]:Vaut2ADDriver ST: Applying to instance #1.
[04/07/21 15:40:46.453]:Vaut2ADDriver ST: Evaluating selection criteria for rule 'Driver-Veto-Testing'.
[04/07/21 15:40:46.453]:Vaut2ADDriver ST: (if-class-name equal "User") = TRUE.
[04/07/21 15:40:46.453]:Vaut2ADDriver ST: Query from policy
[04/07/21 15:40:46.453]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="user" scope="entry">
<association>73dda42b4f84614fa2e5fa2bc364968f</association>
<read-attr attr-name="roomNumber"/>
</query>
</input>
</nds>

Association to this AD object not exist in eDirectory yet:
[04/07/21 15:40:46.454]:Vaut2ADDriver ST: Pumping XDS to eDirectory.
[04/07/21 15:40:46.454]:Vaut2ADDriver ST: Performing operation query for .
[04/07/21 15:40:46.479]:Vaut2ADDriver ST: Query from policy result
[04/07/21 15:40:46.479]:Vaut2ADDriver ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Standard" version="4.5.6.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status level="error">Code(-9039) Element &lt;query> does not have a valid association.</status>
</output>
</nds>

The result of your custom (unnecessary) query from Pub-ITP-Driver-Veto overrides original matching results to an empty document.
The matching policy never get results

[04/07/21 15:40:46.490]:Vaut2ADDriver ST: Resolving association references.
[04/07/21 15:40:46.491]:Vaut2ADDriver ST: Query from policy result
[04/07/21 15:40:46.491]:Vaut2ADDriver ST:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20140409_120000" instance="\VAULT\Organazation\idm\IDM_Vault\Vaut2AD" version="4.0.0.4">AD</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status event-id="0" level="success"/>
</output>
</nds>
[04/07/21 15:40:46.491]:Vaut2ADDriver ST: No matches found.



The issue in your custom (strange) policy Pub-ITP-Driver-Veto.

View solution in original post

Micro Focus Expert
Micro Focus Expert

@dkoepke ,

As @al_b states, the issue is with your policy Pub-ITP-Driver-Veto. If you wish to Veto inbound User operations (Add, Modify, etc) you need to change your conditions to test for more than just class=User and add a test for the operation type to limit the action to just the operations you want to Veto. In this case you are Vetoing the Instance returned as the result of your original Query from the Subscriber Matching Policy.

Scoping operations correctly to allow further processing or not, is a critical piece that I see missing in far too many policies. (Including some of the out-of-the-box policies in some drivers.) By not scoping the policies well, there are often Actions taken that generate extra processing, or cause unintended consequences, such as the one you have encountered in this situation.

I recommend that all policies include a scoping Rule at the beginning that breaks out of the policy and any further processing if there is no work to be done for the operation in the policy. (I believe this is a Best Practice.) A good scoping first Rule would look something like:

	<rule>
		<description>Break if Not a User Add or Modify operation</description>
		<comment xml:space="preserve">Break if this is not a User Add or Modify operation as there is no work to be done in this policy.</comment>
		<conditions>
			<or>
				<if-class-name mode="nocase" op="not-equal">User</if-class-name>
				<if-operation mode="regex" op="not-equal">add|modify</if-operation>
			</or>
		</conditions>
		<actions>
			<do-break/>
		</actions>
	</rule>

After a scoping Rule, multiple Rules can then work on the operation as desired and be ignored for operations that do not need to be processed by those additional Rules.

If there is only a single Rule needed in a Policy, it is reasonable to adjust the Conditions to allow only the types of operations you want to be processed. This may cause issues later, if the Policy is changed and additional Rules are added. By including the initial Scoping Rule, you tend to future proof yourself to allow additional Rules to be added later.

For your situation, which looks to be a single Rule, this logic could be applied to look something like:

	<rule>
		<description>Driver Veto Testing</description>
		<comment xml:space="preserve">Veto all User Operations during driver testing. Allow Query and Instance to flow through.</comment>
		<conditions>
			<and>
				<if-class-name mode="nocase" op="equal">User</if-class-name>
				<if-operation mode="regex" op="equal">add|delete|modify|move|rename</if-operation>
			</and>
		</conditions>
		<actions>
			{include the Actions you want to process here}
		</actions>
	</rule>

The key is to block (or process) only the operations you want to impact and not all operations that might be passing through the Policy.

Hope this provides some suggestions for you.

Cheers,

D

Lieutenant Commander
Lieutenant Commander

Thanks

The reason for the roomNumber = test rule is to check is to isolate the changes made to AD from the Vault and to the Vault from AD. I place a check in both channels on both of the two AD drivers because I was worried about both drivers trying apply changes to the single AD object. The roomNumber attribute resides on the object in the Vault

That policy is in the publisher channel. I have the same check in both channels on both drivers. Old driver will veto if roomNumber not equal test and the new driver will allow process if the roomNumber equal test. The policy is below.

I'll try disabling the veto rules and test some users.

Thanks for your help

Dan

<?xml version="1.0" encoding="UTF-8"?><policy>
<rule>
<description>Driver-Veto-Testing</description>
<comment xml:space="preserve">This rule is setup for testing the driver in parallel with the old production driver.
We check the roomNUmber attribute for a value of "Test".
If the value is not test then we veto the action</comment>
<conditions>
<and>
<if-class-name mode="nocase" op="equal">User</if-class-name>
<if-dest-attr class-name="User" mode="nocase" name="roomNumber" op="not-equal">test</if-dest-attr>
</and>
</conditions>
<actions>
<do-veto/>
</actions>
</rule>
</policy>

0 Likes
Commodore
Commodore

As al_b and dstagg pointed out you just need to modify your policy. dstagg had a good general recommendation and quick solution to your problem, al_b didn't hand out the solution to correcting it, but pointed you to the problem.

Now my more specific answer is correct if you are looking at the roomNumber attribute in AD and not IDV.
Problem is this line:
<if-dest-attr class-name="User" mode="nocase" name="roomNumber" op="not-equal">test</if-dest-attr>
it should be if the source (AD) attribute and not if destination (IDV) attribute because the user is not yet associated therefore we cannot get IDV roomNumber, the error is encountered because this user was just matched and the association was given but the actual association is not yet written, therefore association is reported invalid.

Explanation, which might confuse a lot...
source and destination attributes are relative, meaning:
-the source attribute on the subscriber channel will be IDV, while on the publisher channel that would be attribute in AD (itp policyset sort of belongs to the publisher).
-the destination attribute on the subscriber channel is in AD, while on the publisher it is IDV

Now if you really want to look at the IDV attribute... I presume users will only be matched and not created, therefore you must create a creation policy that vetoes any user event (therefore vetoes user creation). Then move your policy from itp to ctp policyset, but some policies before your ctp policy might write directly to IDV or AD so watch out for that...

Disclaimer, you might know all of this stuff and I was the one that misunderstood the problem.

0 Likes
Lieutenant Commander
Lieutenant Commander

I want to thank everyone for their input.

Great advice and adding different prospective to the issue.

I'm going to test al_b solution and disable the set of roomNumber veto rules.

This company has about 30,000 users and no test environment, so I need to step slow with caution. I schedule this test for this evening.

I may have to push the migration to the  new driver and deal with any issues.

A side note: I understand that source and destination attributes are relative based on the channel and both rules reflect the difference. a area that I was wondering  about the execution of the veto policy

[04/07/21 15:40:46.452]:Vaut2ADDriver ST: Applying policy: %+C%14CPub-ITP-Driver-Veto%-C.

That policy is in the publisher channel.

Is the document returned from the remote loader sent back via the publisher channel?

Is this why the subscriber channel is executing policies defined in the publisher channel?

Just a question to help me understand the way data flows and polices are used.

Again Thanks to everyone for their great input

Dan

0 Likes
Commodore
Commodore

Is the document returned from the remote loader sent back via the publisher channel?
"kind of" basically (itp policyset is not actually part of the publisher channel), but yes itp policyset is applied to every document returned by remote loader shim (in your case matching user with the same displayName on AD was returned)


Is this why the subscriber channel is executing policies defined in the publisher channel?
This all still actually is subscriber channel event but because the query was started its policy flow is OTP before sending to SHIM and the ITP policyset after returning the event from SHIM

Policyflow is in my opinion one of the important basics, which surprised me the most when writing policies from starting to work with IDM.
I have saved the link to some really useful descriptions of the policy flow which I haven't had time to read yet ':D, but I am not sure this is the right one:
https://www.novell.com/documentation/idm35/policy/data/policytypesoverview.html
Perhaps this?
https://community.microfocus.com/t5/Identity-Manager-Tips/A-Guided-Tour-of-Novell-Identity-Manager-Part-3/ta-p/1776081

0 Likes
Micro Focus Expert
Micro Focus Expert

In reply to:

A side note: I understand that source and destination attributes are relative based on the channel and both rules reflect the difference. a area that I was wondering about the execution of the veto policy

[04/07/21 15:40:46.452]:Vaut2ADDriver ST: Applying policy: %+C%14CPub-ITP-Driver-Veto%-C.

That policy is in the publisher channel.

Is the document returned from the remote loader sent back via the publisher channel?

Is this why the subscriber channel is executing policies defined in the publisher channel?

Just a question to help me understand the way data flows and polices are used.

Your policy is NOT in the Publisher channel but in the Input Transform Policy Set. The Output. Input and Schema policy sets are actually implemented twice in the driver as part of the Translation Processor. One instance on the Subscriber channel and one instance on the Publisher channel. This means that all returns for output (query, status) on the Subscriber channel is received by the Subscriber instance. The responses will flow through the Subscriber instance of the Input Transform policies and the Schema Policies before being returned to the calling routine. This is so that the response information is correctly transformed from the Application Name Space to the eDirectory Name Space. If there are new operations generated during the input (response transform) process, those operations will be passed to the Publisher channel for processing following the Schema policies.

Update: The article Comprehending IDM Traces - Part 1 by @ffreitas covers what I was trying to describe above. It provides a great review of how the Input, Output, Schema and Association Reference processor are independent of the Publisher and Subscriber channels and are instantiated by both channels.

One final note on this topic. The placement of your Veto Policy, would be better located in the Publisher Event Transform set, where it is truly in the Publisher channel. Then you would likely be able to use it as you originally intended. Although many policies get added to the Input and Output policy sets, it is best practice to keep these policies limited to ones that are directly involved in the transformation from one name space to the other. @aburgemeister provides some great details and thoughts on this aspect in his IDM Proven Practices: Efficient IDM Input/Output Transformation Value Mappings article.

Cheers,

D

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.