Anonymous_User Absent Member.
Absent Member.
309 views

XPATH query confusion

Hello,

I am trying to write a rule which will, when it receives a password
change event for a user, query a specific group in AD to see if that
user is a member... or else query the'memberOf' pseudo-attribute for
the user and see if the specific group is listed.

I know that if I use either approach, I will need to use XPATH and a
for-each statement.
For the first approach, I would query for all members of the specific
group and iterate over them looking for the user in question, and for
the second approach I would iterate over all groups the user is a member
of until it finds a match. I'm stuck on which is the better approach and
exactly how to construct the query.

Can someone steer me toward a useful XPATH tutorial with gobs of examples?

Thanks
Labels (1)
0 Likes
19 Replies
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

On 5/16/2019 11:20 AM, 6423241 wrote:
> Hello,
>
> I am trying to write a rule which will, when it receives a password
> change event for a user, query a specific group in AD to see if that
> user is a member...  or else query the'memberOf' pseudo-attribute for
> the user and see if the specific group is listed.
>
> I know that if I use either approach, I will need to use XPATH and a
> for-each statement.
> For the first approach, I would query for all members of the specific
> group and iterate over them looking for the user in question, and for
> the second approach I would iterate over all groups the user is a member
> of until it finds a match. I'm stuck on which is the better approach and
> exactly how to construct the query.
>
> Can someone steer me toward a useful XPATH tutorial with gobs of examples?


Beetlejuice?

XPATH:

Concepts:
http://www.novell.com/communities/node/4833/some-thoughts-xpath-novell-identity-manager
https://www.netiq.com/communities/cool-solutions/xpath-and-context-node/
http://www.novell.com/communities/node/6109/xpath-and-math
http://www.novell.com/communities/node/6179/using-string-compares-xpath-statements
http://www.novell.com/communities/node/6910/another-attempt-explaining-xpath-context-node
http://www.novell.com/communities/node/9214/example-walk-through-using-xpath-identity-manager
http://www.novell.com/communities/node/12361/examples-using-xpath-identity-manager
http://www.novell.com/communities/node/13617/xpath-and-the-four-contexts

Cool tips:
http://www.novell.com/communities/node/5845/using-xpath-examine-association-values
https://www.netiq.com/communities/cool-solutions/cool-tricks-using-xpath-nodesets/
http://www.novell.com/communities/node/4825/using-global-configuration-values-xpath
http://www.novell.com/communities/node/6276/using-xpath-get-position-node-node-set

http://www.novell.com/communities/node/11637/xpath-do-schema-mapping-rule
http://www.novell.com/communities/node/12261/using-xpath-reproduce-map-token


However those are all redirected to the new Community site as of last
week or so and I am not sure if all will redirect properly. Let me
know, and I will get you the proper URL.

Argh, I am getting bad redirects on some, and the URL I get when I
search on commuinity looks like:
https://community.microfocus.com/t5/Identity-Manager-Tips/Examples-of-using-XPATH-in-Identity-Manager/ta-p/1773331?advanced=false&collapse_discussion=true&filter=includeTkbs,location&include_tkbs=true&location=tkb-board:Identity_Mgr_Tips&q=xpath%20example&search_type=thread

Ok, can ditch all the crap at the end...

https://community.microfocus.com/t5/Identity-Manager-Tips/Examples-of-using-XPATH-in-Identity-Manager/ta-p/1773331

But more specifically, you could for-each over a Query token, for what
you want.

But you could instead get dest-attr of object CN GroupName, attribute
member, into a nodeset variable, then If local variable $varName = LDAP
DN of group, exact case match then it will return true if present, false
if absent.

I am NOT sure if the query can handle a group with hmore than 1500
members, since AD does not like to return more than 1500 attribute
VALUES in a single requrst.


0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

6423241 wrote:

> I know that if I use either approach, I will need to use XPATH and a for-each
> statement.


Not necessarily. You could query for the group as search base and
member=<user-dn> as matching criteria. Now if you get back an <instance> the
user is a group member, if you do not get any <instance> back, it's not.
Not sure how well that works with the AD shim's query capabilities. It will
certainly work with Edir and LDAP

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: XPATH query confusion

Lothar Haeger,
>
>> I know that if I use either approach, I will need to use XPATH and a for-each
>> statement.

>
> Not necessarily. You could query for the group as search base and
> member=<user-dn> as matching criteria. Now if you get back an <instance> the
> user is a group member, if you do not get any <instance> back, it's not.
> Not sure how well that works with the AD shim's query capabilities. It will
> certainly work with Edir and LDAP
>


It's worth a try, especially since all but a few of the links Geoffrey
helpfully provided return "Page Not Found".

Thanks


0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

On 5/16/2019 1:26 PM, 6423241 wrote:
> Lothar Haeger,
>>
>>> I know that if I use either approach, I will need to use XPATH and a
>>> for-each
>>> statement.

>>
>> Not necessarily. You could query for the group as search base and
>> member=<user-dn> as matching criteria. Now if you get back an
>> <instance> the
>> user is a group member, if you do not get any <instance> back, it's not.
>> Not sure how well that works with the AD shim's query capabilities. It
>> will
>> certainly work with Edir and LDAP
>>

>
> It's worth a try, especially since all but a few of the links Geoffrey
> helpfully provided return "Page Not Found".


Ya, annoying. The ladies working on this have the remapping list and
are working on getting it all done. So these are supposed to start
working again at some point soon.

Go to community.microfocus.com and search for any words in the URL or
topics and you will likely find the article.

LOthars approach is even simpler than mine.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: XPATH query confusion

Lothar Haeger,

> 6423241 wrote:
>
>> I know that if I use either approach, I will need to use XPATH and a for-each
>> statement.

>
> Not necessarily. You could query for the group as search base and
> member=<user-dn> as matching criteria. Now if you get back an <instance> the
> user is a group member, if you do not get any <instance> back, it's not.
> Not sure how well that works with the AD shim's query capabilities. It will
> certainly work with Edir and LDAP
>


So I want to do a query of the destination datastore, scope Subtree,
class name group, specified DN = [dn of target group], match attributes
member...

I'm bogged down at the <user DN> bit. Given that the user I'm looking
for could be in one of many OUs on the MAD side and a user CN in the ID
vault is not the same as CN in MAD, what specific value am I matching on?



Thanks
0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

On 5/20/2019 4:05 PM, 6423241 wrote:
> Lothar Haeger,
>
>> 6423241 wrote:
>>
>>> I know that if I use either approach, I will need to use XPATH and a
>>> for-each
>>> statement.

>>
>> Not necessarily. You could query for the group as search base and
>> member=<user-dn> as matching criteria. Now if you get back an
>> <instance> the
>> user is a group member, if you do not get any <instance> back, it's not.
>> Not sure how well that works with the AD shim's query capabilities. It
>> will
>> certainly work with Edir and LDAP
>>

>
> So I want to do a query of the destination datastore, scope Subtree,
> class name group, specified DN = [dn of target group], match attributes
> member...
>
> I'm bogged down at the <user DN> bit. Given that the user I'm looking
> for could be in one of many OUs on the MAD side and a user CN in the ID
> vault is not the same as CN in MAD, what specific value am I matching on?


Are all your users associated? Look at DirXML-ADContext in the IDV to
get the DN in AD. Or use the Resolve token to convert the Assoc value
on the user for this driver, to the DN in the remote source.
0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

6423241 wrote:

> So I want to do a query of the destination datastore, scope Subtree, class
> name group, specified DN = [dn of target group], match attributes member...


Scope should be "base" (search only this single DN/group), though "subtree"
would probably work as well, since groups are non-containers

> I'm bogged down at the <user DN> bit. Given that the user I'm looking for
> could be in one of many OUs on the MAD side and a user CN in the ID vault is
> not the same as CN in MAD, what specific value am I matching on?


Simply use token-src-dn. If you're on the publisher (were does your pw change
event come from? AD or Edir), it's already the DN in AD. If on the subscriber,
it should be resolved to that user's association in schema mapping and
@association-ref will be added to the <value> node automatically.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: XPATH query confusion

On 5/21/2019 04:28, Lothar Haeger wrote:
> 6423241 wrote:
>
>> So I want to do a query of the destination datastore, scope Subtree, class
>> name group, specified DN = [dn of target group], match attributes member...

>
> Scope should be "base" (search only this single DN/group), though "subtree"
> would probably work as well, since groups are non-containers
>
>> I'm bogged down at the <user DN> bit. Given that the user I'm looking for
>> could be in one of many OUs on the MAD side and a user CN in the ID vault is
>> not the same as CN in MAD, what specific value am I matching on?

>
> Simply use token-src-dn. If you're on the publisher (were does your pw change
> event come from? AD or Edir), it's already the DN in AD. If on the subscriber,
> it should be resolved to that user's association in schema mapping and
> @association-ref will be added to the <value> node automatically.
>


Password change events come from the vault, so I'm creating the rule in
the ETP on the subscriber channel. There isn't a scope 'base' -- how
about 'entry'? The other option is 'subordinates'.

0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

6423241 wrote:

> There isn't a scope 'base' -- how about 'entry'?


That's the one. Funny how they reinvent terminology in Designer - to "simplify"
the user experience, I guess.

Similar thing with subversion commit (which is called "check in" in Designer)

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: XPATH query confusion

Here is my rule:


<rule>
<description>identify users in StaleUsers group </description>
<conditions>
<and>
<if-class-name mode="nocase" op="equal">User</if-class-name>
<if-operation mode="nocase" op="equal">modify</if-operation>
</and>
</conditions>
<actions>
<do-set-local-variable name="lv-isMember" scope="driver">
<arg-node-set>
<token-query class-name="group" datastore="dest" scope="entry">
<arg-dn>
<token-text
xml:space="preserve">CN=Stale_Osumc.Users,OU=Application,OU=Access
Groups,DC=OSUMC,DC=EDU</token-text>
</arg-dn>
<arg-match-attr name="member">
<arg-value type="dn">
<token-src-dn/>
</arg-value>
</arg-match-attr>
</token-query>
</arg-node-set>
</do-set-local-variable>
<do-if>
<arg-conditions>
<and>
<if-xpath op="true">count($lv-isMember/@src-dn)=1</if-xpath>
</and>
</arg-conditions>
<arg-actions>
<do-add-src-attr-value name="IWS:User Comment">
<arg-value type="string">
<token-text xml:space="preserve">Bingo!</token-text>
</arg-value>
</do-add-src-attr-value>
</arg-actions>
<arg-actions/>
</do-if>
</actions>
</rule>


The trace returns a status message that says:
<message>Error getting next page of search results</message>
<ldap-err ldap-rc="10" ldap-rc-name="LDAP_REFERRAL">

Full L3 trace is here: https://pastebin.com/0kURsNzh

I think I'm closer to pay dirt, but something is still missing.

Thanks
0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

6423241 wrote:

> <message>Error getting next page of search results</message>
> <ldap-err ldap-rc="10" ldap-rc-name="LDAP_REFERRAL">


That error message seem not exactly spot-on. When I look at the query you
send...

<query class-name="group"
dest-dn="CN=Stale_Osumc.Users,OU=Application,OU=Access Groups,DC=OSUMC,DC=EDU"
event-id="0" scope="entry">
<search-attr attr-name="member">
<value type="dn">\IDMTEST1\osumc\users\smit01</value>
</search-attr>
<read-attr/>
</query>

....a few things come to mind:

- you query by @dest-dn, not by association. That might work or not, depending
on the shim. Recently I was working with an LDAP driver and it seemed the shim
was not able to use @dest-dn (not sure if it was for modifies or queries,
though) and failed unless I set an association. Funny enough the association
value for the LDAP shim *IS* the FQDN, so all I had to do was copy @dest-dn to
association/text()...
Not sure about the amount of (artificial or natural) intelligence built into
the AD shim, but an association may be required. Token-resolve should be able
to fix that for you.

- CN=Stale_Osumc.Users,OU=Application,... looks like a strange object name,
sure this is correct? Dots in naming attributes need to be escaped in Edir, not
sure about AD. Token "Escape for Dest DN" may be helpful.

- the value of the member attribute is given in slash syntax, which AD
definitely does not understand. Try to convert to LDAP format or even better
set @association-ref on the value node (again token-resolve can help here).

You should get to something like

<query class-name="group"
dest-dn="CN=Stale_Osumc.Users,OU=Application,OU=Access Groups,DC=OSUMC,DC=EDU"
event-id="0" scope="entry">
<association state="associated">(group's association)</association>
<search-attr attr-name="member">
<value association-ref="(user's association)"
type="dn">\IDMTEST1\osumc\users\smit01</value>
</search-attr>
<read-attr/>
</query>


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

On 5/29/2019 9:49 AM, 6423241 wrote:
> Here is my rule:
>
>

> <rule>
>         <description>identify users in StaleUsers group </description>
>         <conditions>
>             <and>
>                 <if-class-name mode="nocase"
> op="equal">User</if-class-name>
>                 <if-operation mode="nocase"
> op="equal">modify</if-operation>
>             </and>
>         </conditions>
>         <actions>
>             <do-set-local-variable name="lv-isMember" scope="driver">
>                 <arg-node-set>
>                     <token-query class-name="group" datastore="dest"
> scope="entry">
>                         <arg-dn>
>                             <token-text
> xml:space="preserve">CN=Stale_Osumc.Users,OU=Application,OU=Access
> Groups,DC=OSUMC,DC=EDU</token-text>
>                         </arg-dn>
>                         <arg-match-attr name="member">
>                             <arg-value type="dn">
>                                 <token-src-dn/>
>                             </arg-value>
>                         </arg-match-attr>
>                     </token-query>
>                 </arg-node-set>
>             </do-set-local-variable>
>             <do-if>
>                 <arg-conditions>
>                     <and>
>                         <if-xpath
> op="true">count($lv-isMember/@src-dn)=1</if-xpath>
>                     </and>
>                 </arg-conditions>
>                 <arg-actions>
>                     <do-add-src-attr-value name="IWS:User Comment">
>                         <arg-value type="string">
>                             <token-text
> xml:space="preserve">Bingo!</token-text>
>                         </arg-value>
>                     </do-add-src-attr-value>
>                 </arg-actions>
>                 <arg-actions/>
>             </do-if>
>         </actions>
>     </rule>
>

>
> The trace returns a status message that says:
>      <message>Error getting next page of search results</message>
>       <ldap-err ldap-rc="10" ldap-rc-name="LDAP_REFERRAL">
>
> Full L3 trace is here:  https://pastebin.com/0kURsNzh


Your Query, correctly uses the AD group DN. But it asks if the eDir
user DN is a member which is incorrect.

But the engine is clever and converts it by adding an @association-ref
value which is good:

[05/29/19 08:30:07.192]:AD-OSUMC ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Advanced" version="4.6.3.0">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<query class-name="group"
dest-dn="CN=Stale_Osumc.Users,OU=Application,OU=Access
Groups,DC=OSUMC,DC=EDU" event-id="0" scope="entry">
<search-attr attr-name="member">
<value association-ref="d14f032920680e44a1ec6a7f1bfc63e9"
type="dn">\IDMTEST1\osumc\users\smit01</value>
</search-attr>
<read-attr/>
</query>
</input>
</nds>

But then you have a policy that removes it:

[05/29/19 08:30:07.193]:AD-OSUMC ST: Applying policy:
%+C%14COSUMC-otp-AttributeTranslations%-C.
[05/29/19 08:30:07.193]:AD-OSUMC ST: Applying to query #1.
[05/29/19 08:30:07.193]:AD-OSUMC ST: Evaluating selection
criteria for rule 'OSU Reformat member to dn'.
[05/29/19 08:30:07.193]:AD-OSUMC ST: (if-class-name
equal "group") = TRUE.
[05/29/19 08:30:07.193]:AD-OSUMC ST: Rule selected.
[05/29/19 08:30:07.193]:AD-OSUMC ST: Applying rule 'OSU
Reformat member to dn'.
[05/29/19 08:30:07.194]:AD-OSUMC ST: Action:
do-reformat-op-attr("member",token-local-variable("current-value")).
[05/29/19 08:30:07.194]:AD-OSUMC ST:
arg-string(token-local-variable("current-value"))
[05/29/19 08:30:07.194]:AD-OSUMC ST:
token-local-variable("current-value")
[05/29/19 08:30:07.194]:AD-OSUMC ST: Token Value:
"\IDMTEST1\osumc\users\smit01".
[05/29/19 08:30:07.194]:AD-OSUMC ST: Arg Value:
"\IDMTEST1\osumc\users\smit01".

The reformat strips off the association-ref. Not sure why you are doing
that.


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: XPATH query confusion

On 5/29/2019 13:19, Geoffrey Carman wrote:
> On 5/29/2019 9:49 AM, 6423241 wrote:
>> Here is my rule:
>>
>>

<snip>
>>
>> The trace returns a status message that says:
>>       <message>Error getting next page of search results</message>
>>        <ldap-err ldap-rc="10" ldap-rc-name="LDAP_REFERRAL">
>>
>> Full L3 trace is here:  https://pastebin.com/0kURsNzh

>
> Your Query, correctly uses the AD group DN.  But it asks if the eDir
> user DN is a member which is incorrect.
>
> But the engine is clever and converts it by adding an @association-ref
> value which is good:
>
> [05/29/19 08:30:07.192]:AD-OSUMC ST:
> <nds dtdversion="4.0" ndsversion="8.x">
>   <source>
>     <product edition="Advanced" version="4.6.3.0">DirXML</product>
>     <contact>NetIQ Corporation</contact>
>   </source>
>   <input>
>     <query class-name="group"
> dest-dn="CN=Stale_Osumc.Users,OU=Application,OU=Access
> Groups,DC=OSUMC,DC=EDU" event-id="0" scope="entry">
>       <search-attr attr-name="member">
>         <value association-ref="d14f032920680e44a1ec6a7f1bfc63e9"
> type="dn">\IDMTEST1\osumc\users\smit01</value>
>       </search-attr>
>       <read-attr/>
>     </query>
>   </input>
> </nds>
>
> But then you have a policy that removes it:
>
> [05/29/19 08:30:07.193]:AD-OSUMC ST:            Applying policy:
> %+C%14COSUMC-otp-AttributeTranslations%-C.
> [05/29/19 08:30:07.193]:AD-OSUMC ST:              Applying to query #1.
> [05/29/19 08:30:07.193]:AD-OSUMC ST:                Evaluating selection
> criteria for rule 'OSU Reformat member to dn'.
> [05/29/19 08:30:07.193]:AD-OSUMC ST:                  (if-class-name
> equal "group") = TRUE.
> [05/29/19 08:30:07.193]:AD-OSUMC ST:                Rule selected.
> [05/29/19 08:30:07.193]:AD-OSUMC ST:                Applying rule 'OSU
> Reformat member to dn'.
> [05/29/19 08:30:07.194]:AD-OSUMC ST:                  Action:
> do-reformat-op-attr("member",token-local-variable("current-value")).
> [05/29/19 08:30:07.194]:AD-OSUMC ST:
> arg-string(token-local-variable("current-value"))
> [05/29/19 08:30:07.194]:AD-OSUMC ST: token-local-variable("current-value")
> [05/29/19 08:30:07.194]:AD-OSUMC ST:                        Token Value:
> "\IDMTEST1\osumc\users\smit01".
> [05/29/19 08:30:07.194]:AD-OSUMC ST:                      Arg Value:
> "\IDMTEST1\osumc\users\smit01".
>
> The reformat strips off the association-ref.  Not sure why you are doing
> that.
>


I inherited the management of this system, so there's a lot that I just
took on faith as being necessary. Here's the description for that rule.

"Reformat the member strings to dn syntax. This is necessary to keep
Novell from trying to resolve it to the vault."

I'll try disabling that rule and see what breaks.

Thanks



0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: XPATH query confusion

On 5/29/2019 1:30 PM, 6423241 wrote:
> On 5/29/2019 13:19, Geoffrey Carman wrote:
>> On 5/29/2019 9:49 AM, 6423241 wrote:
>>> Here is my rule:
>>>
>>>

> <snip>
>>>
>>> The trace returns a status message that says:
>>>       <message>Error getting next page of search results</message>
>>>        <ldap-err ldap-rc="10" ldap-rc-name="LDAP_REFERRAL">
>>>
>>> Full L3 trace is here:  https://pastebin.com/0kURsNzh

>>
>> Your Query, correctly uses the AD group DN.  But it asks if the eDir
>> user DN is a member which is incorrect.
>>
>> But the engine is clever and converts it by adding an @association-ref
>> value which is good:
>>
>> [05/29/19 08:30:07.192]:AD-OSUMC ST:
>> <nds dtdversion="4.0" ndsversion="8.x">
>>    <source>
>>      <product edition="Advanced" version="4.6.3.0">DirXML</product>
>>      <contact>NetIQ Corporation</contact>
>>    </source>
>>    <input>
>>      <query class-name="group"
>> dest-dn="CN=Stale_Osumc.Users,OU=Application,OU=Access
>> Groups,DC=OSUMC,DC=EDU" event-id="0" scope="entry">
>>        <search-attr attr-name="member">
>>          <value association-ref="d14f032920680e44a1ec6a7f1bfc63e9"
>> type="dn">\IDMTEST1\osumc\users\smit01</value>
>>        </search-attr>
>>        <read-attr/>
>>      </query>
>>    </input>
>> </nds>
>>
>> But then you have a policy that removes it:
>>
>> [05/29/19 08:30:07.193]:AD-OSUMC ST:            Applying policy:
>> %+C%14COSUMC-otp-AttributeTranslations%-C.
>> [05/29/19 08:30:07.193]:AD-OSUMC ST:              Applying to query #1.
>> [05/29/19 08:30:07.193]:AD-OSUMC ST:                Evaluating
>> selection criteria for rule 'OSU Reformat member to dn'.
>> [05/29/19 08:30:07.193]:AD-OSUMC ST:                  (if-class-name
>> equal "group") = TRUE.
>> [05/29/19 08:30:07.193]:AD-OSUMC ST:                Rule selected.
>> [05/29/19 08:30:07.193]:AD-OSUMC ST:                Applying rule 'OSU
>> Reformat member to dn'.
>> [05/29/19 08:30:07.194]:AD-OSUMC ST:                  Action:
>> do-reformat-op-attr("member",token-local-variable("current-value")).
>> [05/29/19 08:30:07.194]:AD-OSUMC ST:
>> arg-string(token-local-variable("current-value"))
>> [05/29/19 08:30:07.194]:AD-OSUMC ST:
>> token-local-variable("current-value")
>> [05/29/19 08:30:07.194]:AD-OSUMC ST:                        Token
>> Value: "\IDMTEST1\osumc\users\smit01".
>> [05/29/19 08:30:07.194]:AD-OSUMC ST:                      Arg Value:
>> "\IDMTEST1\osumc\users\smit01".
>>
>> The reformat strips off the association-ref.  Not sure why you are
>> doing that.
>>

>
> I inherited the management of this system, so there's a lot that I just
> took on faith as being necessary. Here's the description for that rule.
>
> "Reformat the member strings to dn syntax. This is necessary to keep
> Novell from trying to resolve it to the vault."


It feels like this is on the wrong channel. And should instead be on
the Pub channel.

In the response, if you query a group, and it comes back with members,
they will be in the AD format, and if that user is not associated in
eDir it will then be stripped from the document. Which you MIGHT want to
block. Which this rule and description probably would accomplish.

BUt this is going the other direction.

You could solve this, by using the Resolve token to get the AD DN of the
user (or just use DirXML-ADContext) as the value for the group member
you are querying.


0 Likes
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.