mjstew

Lieutenant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2018-06-07
19:41
556 views
Rewriting DNs in the Member attribute of a Group Sync Event
Hello!
I am writing an eDirectory to eDirectory driver in which I need to rewrite the DNs of the Group object's Member attribute to the format used in my directory. The event is coming from a source eDirectory with a different OU layout.
I was planning to do this in the publisher command transform, but for the life of me I can't figure out the best way of doing this.
- A policy would be better for the DN manipulation (finding the leaf object, then rewriting it in the new DN format).
- XSLT seems easier for reconstructing the event, then matching on the Member attribute to rewrite the DNs in the value, add-value, or remove-value nodes.
What are your thoughts? Any code examples you could share would be most appreciated.
Thanks,
Jack Stewart
University of Michigan
I am writing an eDirectory to eDirectory driver in which I need to rewrite the DNs of the Group object's Member attribute to the format used in my directory. The event is coming from a source eDirectory with a different OU layout.
I was planning to do this in the publisher command transform, but for the life of me I can't figure out the best way of doing this.
- A policy would be better for the DN manipulation (finding the leaf object, then rewriting it in the new DN format).
- XSLT seems easier for reconstructing the event, then matching on the Member attribute to rewrite the DNs in the value, add-value, or remove-value nodes.
What are your thoughts? Any code examples you could share would be most appreciated.
Thanks,
Jack Stewart
University of Michigan
4 Replies


Knowledge Partner
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2018-06-07
20:21
On 6/7/2018 2:44 PM, mjstew wrote:
>
> Hello!
>
> I am writing an eDirectory to eDirectory driver in which I need to
> rewrite the DNs of the Group object's Member attribute to the format
> used in my directory. The event is coming from a source eDirectory with
> a different OU layout.
>
> I was planning to do this in the publisher command transform, but for
> the life of me I can't figure out the best way of doing this.
>
> - A policy would be better for the DN manipulation (finding the leaf
> object, then rewriting it in the new DN format).
> - XSLT seems easier for reconstructing the event, then matching on the
> Member attribute to rewrite the DNs in the value, add-value, or
> remove-value nodes.
>
> What are your thoughts? Any code examples you could share would be most
> appreciated.
Are the member's existing users in both systems and associated?
If so, although the event with the DN type values will have the other
tree's DN's they should have an association-ref="AssocValue" and when it
comes time to write the values to this eDir, the assocValue is looked up
to find the proper DN.
>
> Hello!
>
> I am writing an eDirectory to eDirectory driver in which I need to
> rewrite the DNs of the Group object's Member attribute to the format
> used in my directory. The event is coming from a source eDirectory with
> a different OU layout.
>
> I was planning to do this in the publisher command transform, but for
> the life of me I can't figure out the best way of doing this.
>
> - A policy would be better for the DN manipulation (finding the leaf
> object, then rewriting it in the new DN format).
> - XSLT seems easier for reconstructing the event, then matching on the
> Member attribute to rewrite the DNs in the value, add-value, or
> remove-value nodes.
>
> What are your thoughts? Any code examples you could share would be most
> appreciated.
Are the member's existing users in both systems and associated?
If so, although the event with the DN type values will have the other
tree's DN's they should have an association-ref="AssocValue" and when it
comes time to write the values to this eDir, the assocValue is looked up
to find the proper DN.
mjstew

Lieutenant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2018-06-08
16:41
Although the source tree and target tree groups will have an association, the user objects in the Member attribute will not have an association between trees.
I've been reading and I think I have something to deal with the operational (i.e., added) attributes:
<rule>
<description>Modify DNs: Added Attributes</description>
<conditions>
<and>
<if-operation mode="nocase" op="equal">modify</if-operation>
<if-op-attr name="Member" op="available"/>
</and>
</conditions>
<actions>
<do-for-each>
<arg-node-set>
<token-text xml:space="preserve">Member</token-text>
</arg-node-set>
<arg-actions>
<do-set-local-variable name="old-dn" scope="policy">
<arg-string>
<token-text xml:space="preserve">$current-node</token-text>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="uniqname" scope="policy">
<arg-string>
<token-parse-dn length="1" start="-1"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="new-dn" scope="policy">
<arg-string>
<token-text xml:space="preserve">edu\umich\Groups\User Groups</token-text>
<token-local-variable name="$uniqname$"/>
</arg-string>
</do-set-local-variable>
<do-strip-xpath expression='modify-attr[@attr-name="Member"]/value/text()'/>
<do-append-xml-text expression='modify-attr[@attr-name="Member]/add-value/value'>
<arg-string>
<token-text xml:space="preserve">$new-dn</token-text>
</arg-string>
</do-append-xml-text>
</arg-actions>
</do-for-each>
</actions>
</rule>
But how do I deal with the attributes being removed?
I've been reading and I think I have something to deal with the operational (i.e., added) attributes:
<rule>
<description>Modify DNs: Added Attributes</description>
<conditions>
<and>
<if-operation mode="nocase" op="equal">modify</if-operation>
<if-op-attr name="Member" op="available"/>
</and>
</conditions>
<actions>
<do-for-each>
<arg-node-set>
<token-text xml:space="preserve">Member</token-text>
</arg-node-set>
<arg-actions>
<do-set-local-variable name="old-dn" scope="policy">
<arg-string>
<token-text xml:space="preserve">$current-node</token-text>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="uniqname" scope="policy">
<arg-string>
<token-parse-dn length="1" start="-1"/>
</arg-string>
</do-set-local-variable>
<do-set-local-variable name="new-dn" scope="policy">
<arg-string>
<token-text xml:space="preserve">edu\umich\Groups\User Groups</token-text>
<token-local-variable name="$uniqname$"/>
</arg-string>
</do-set-local-variable>
<do-strip-xpath expression='modify-attr[@attr-name="Member"]/value/text()'/>
<do-append-xml-text expression='modify-attr[@attr-name="Member]/add-value/value'>
<arg-string>
<token-text xml:space="preserve">$new-dn</token-text>
</arg-string>
</do-append-xml-text>
</arg-actions>
</do-for-each>
</actions>
</rule>
But how do I deal with the attributes being removed?


Knowledge Partner
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2018-06-08
16:59
On 06/08/2018 09:44 AM, mjstew wrote:
>
> Although the source tree and target tree groups will have an
> association, the user objects in the Member attribute will not have an
> association between trees.
Just to be sure, have you tried to see if it works already? With the
original eDirectory drivers the User side of the equation is where the
group attribute (Group Membership) was synchronized, not the group side
(Member attribute), so if the groups are associated, I think it should
work already, but your asking here makes me think it does not. Could you
please post a trace of what is wrong at this point?
Is there some reason your user objects would not be associated while your
group objects would? That seems a little backwards.
If you are having values stripped because of a lack of association you can
also convert those DN types to strings and then the processing will not
attempt to resolve the objects and strip them when they are found to be
unassociated.
--
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
>
> Although the source tree and target tree groups will have an
> association, the user objects in the Member attribute will not have an
> association between trees.
Just to be sure, have you tried to see if it works already? With the
original eDirectory drivers the User side of the equation is where the
group attribute (Group Membership) was synchronized, not the group side
(Member attribute), so if the groups are associated, I think it should
work already, but your asking here makes me think it does not. Could you
please post a trace of what is wrong at this point?
Is there some reason your user objects would not be associated while your
group objects would? That seems a little backwards.
If you are having values stripped because of a lack of association you can
also convert those DN types to strings and then the processing will not
attempt to resolve the objects and strip them when they are found to be
unassociated.
--
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


Knowledge Partner
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2018-06-08
17:52
On 6/8/2018 11:44 AM, mjstew wrote:
>
> Although the source tree and target tree groups will have an
> association, the user objects in the Member attribute will not have an
> association between trees.
>
> I've been reading and I think I have something to deal with the
> operational (i.e., added) attributes:
>
> <rule>
> <description>Modify DNs: Added Attributes</description>
> <conditions>
> <and>
> <if-operation mode="nocase" op="equal">modify</if-operation>
> <if-op-attr name="Member" op="available"/>
> </and>
> </conditions>
> <actions>
> <do-for-each>
> <arg-node-set>
> <token-text xml:space="preserve">Member</token-text>
> </arg-node-set>
> <arg-actions>
> <do-set-local-variable name="old-dn" scope="policy">
> <arg-string>
> <token-text xml:space="preserve">$current-node</token-text>
> </arg-string>
> </do-set-local-variable>
> <do-set-local-variable name="uniqname" scope="policy">
> <arg-string>
> <token-parse-dn length="1" start="-1"/>
> </arg-string>
> </do-set-local-variable>
> <do-set-local-variable name="new-dn" scope="policy">
> <arg-string>
> <token-text xml:space="preserve">edu\umich\Groups\User
> Groups</token-text>
> <token-local-variable name="$uniqname$"/>
> </arg-string>
> </do-set-local-variable>
> <do-strip-xpath
> expression='modify-attr[@attr-name="Member"]/value/text()'/>
> <do-append-xml-text
> expression='modify-attr[@attr-name="Member]/add-value/value'>
> <arg-string>
> <token-text xml:space="preserve">$new-dn</token-text>
> </arg-string>
> </do-append-xml-text>
> </arg-actions>
> </do-for-each>
> </actions>
> </rule>
>
> But how do I deal with the attributes being removed?
Are the paths static? I.e. Everyone in one tree is in a single
container, with the same CN in the second tree?
If so you could:
Reformat Op Attr (Member) as a string (Not DN, to avoid getting it
stripped) with the value of ParseDN on Local variable, current-value,
with a length of 1, start of -1. Then append the static text to the
beginning.
This iwll handle add, modify, instance docs, and add or remove of values.
>
> Although the source tree and target tree groups will have an
> association, the user objects in the Member attribute will not have an
> association between trees.
>
> I've been reading and I think I have something to deal with the
> operational (i.e., added) attributes:
>
> <rule>
> <description>Modify DNs: Added Attributes</description>
> <conditions>
> <and>
> <if-operation mode="nocase" op="equal">modify</if-operation>
> <if-op-attr name="Member" op="available"/>
> </and>
> </conditions>
> <actions>
> <do-for-each>
> <arg-node-set>
> <token-text xml:space="preserve">Member</token-text>
> </arg-node-set>
> <arg-actions>
> <do-set-local-variable name="old-dn" scope="policy">
> <arg-string>
> <token-text xml:space="preserve">$current-node</token-text>
> </arg-string>
> </do-set-local-variable>
> <do-set-local-variable name="uniqname" scope="policy">
> <arg-string>
> <token-parse-dn length="1" start="-1"/>
> </arg-string>
> </do-set-local-variable>
> <do-set-local-variable name="new-dn" scope="policy">
> <arg-string>
> <token-text xml:space="preserve">edu\umich\Groups\User
> Groups</token-text>
> <token-local-variable name="$uniqname$"/>
> </arg-string>
> </do-set-local-variable>
> <do-strip-xpath
> expression='modify-attr[@attr-name="Member"]/value/text()'/>
> <do-append-xml-text
> expression='modify-attr[@attr-name="Member]/add-value/value'>
> <arg-string>
> <token-text xml:space="preserve">$new-dn</token-text>
> </arg-string>
> </do-append-xml-text>
> </arg-actions>
> </do-for-each>
> </actions>
> </rule>
>
> But how do I deal with the attributes being removed?
Are the paths static? I.e. Everyone in one tree is in a single
container, with the same CN in the second tree?
If so you could:
Reformat Op Attr (Member) as a string (Not DN, to avoid getting it
stripped) with the value of ParseDN on Local variable, current-value,
with a length of 1, start of -1. Then append the static text to the
beginning.
This iwll handle add, modify, instance docs, and add or remove of values.