IDM Lotus Notes Driver: Understanding Policies Which Modify Notes Group Membership



By: pnuffer

January 25, 2010 10:18 am

Reads: 507

Comments:1

Rating:0

Question: One of the Notes driver features is to add/remove Notes users from a Notes DenyAccess group when that user’s Identity Vault (eDirectory) Login Disabled attribute changes. To accomplish this, the Notes Driver’s command transform policy has a rule which performs this task, that I do not understand. The policy’s rule contains this piece of DirXML Script:

<do-set-xml-attr expression="../modify[@class-name='Group' and
last()]/modify-attr[@attr-name='Member' and
last()]/remove-value[last()]/value[last()]" name="association-ref">
  <arg-string>
    <token-association/>
  </arg-string>
</do-set-xml-attr>

I understand most of the XPATH, but I do not know why the “and last()” portion of the expression is necessary. It seems to be unnecessary….so why not leave it out?

Consider the XPATH expression:

.../modify[@class-name='Group' and last()]/modify-attr[@attr-name='Member' and
last()]/remove-value[last()]/value[last()]"

Without the and last() function, it makes a lot of sense:

.../modify[@class-name='Group']/modify-attr[@attr-name='Member']/remove-value/value]"

That expression is easier to read: “find the modify of a group, with an attribute named ‘Member’, which contains a remove-value, and then select the value node.” (To insert
an XML association-ref attribute, which is what the rule is attempting to do). When, trying to determine the purpose of the last() function, all I can think of is that it’s used to avoid multiple node matching (i.e enforce single node matches). But why would this be necessary in this circumstance?

Answer: Your initial analysis of the expression and your thought regarding the multiple node matching is correct. However, the question is not easily answered, and requires a proper context, or view of the entire policy to best understand the reason for this particular usage of the last() function within the XPATH expression. Managing Notes Groups can be a little tricky. When examining the Notes Driver configuration file, you may notice several XPATH last() functions in the expressions of several different rules. The last() functions serve to pinpoint where association-ref attributes are applied. And even though they may not be necessary in every instance, they are used in a consistent fashion, to better ensure proper handling of Notes Group Membership values within Notes Groups. This consistent usage also allows the rules to be more easily ported between policies (cut and pasted with minimal or no editing).

Below is a rule that uses the DirXML script actions referenced in the question. I have included an over-generous dose of comments to hopefully explain why the XPATH last() function is used. When viewing the entire rule (instead of a smaller snippet, as in the question), it is easier to understand why the XPATH expressions use last().

<rule>
  <description>Disable access for Notes Users when eDirectory 'Login Disabled' attribute is set true</description>
  <!--Check for a modify user operation where the eDir Login Disabled attribute has--> 
  <!-- been toggled to true and a Notes DenyAccess Group UNID exists.-->
  <conditions>
    <and>
      <if-class-name mode="nocase" op="equal">User</if-class-name>
      <if-operation op="equal">modify</if-operation>
      <if-op-attr mode="nocase" name="Login Disabled" op="changing-to">true</if-op-attr>
      <if-local-variable name="DenyAccessGrpUNID" op="available"/>
      <if-local-variable name="DenyAccessGrpUNID" op="not-equal"/>
    </and>
  </conditions>
  <!--Add the user to the Notes DenyAccess Group-->
  <actions>
    <!--Because we are within the context of a modify user operation we will use -->
    <!--the do-remove-dest-attr-value a little differently. In this case we will set the-->
    <!--class-name to "Group". This will cause a modify group operation to be-->
    <!--created as a sibling to the modify user operation we are working on --> 
    <!-- (appearing immediately following the modify user operation).-->
    <do-remove-dest-attr-value class-name="Group" name="Member">
      <arg-association>
        <token-local-variable name="DenyAccessGrpUNID"/>
      </arg-association>
      <arg-value type="dn">
        <token-src-dn/>
      </arg-value>
    </do-remove-dest-attr-value>
    <!--We now have effectively added a modify group operation to the XDS doc.-->

    <!--Why are we removing the group member and not adding it?-->
    <!--We are simply removing the member prior to adding it as a method of-->
    <!--group membership 'house-keeping'. We don't know if the member-->
    <!--somehow already exists within the group...and if we simply add the-->
    <!--member, we may then have two identical members within the same-->
    <!--group. To avoid this, we attempt to remove the member prior to adding-->
    <!--it. If the member is not present, the remove group member-->
    <!--attempt does nothing, because it can't find a matching value.-->

    <!--The Group Member modification will not be correctly applied by the-->
    <!-- NotesDriverShim unless there is an association-ref attribute indicating-->
    <!-- the user's Notes UNID value. Because we cannot 100% guarantee what-->
    <!-- other operations exist within this XDS document, we need to make sure-->
    <!-- we find the correct modify Group operation (the one we just added).-->
    <!--To do this, we use an XPATH expression that will find the last modify-->
    <!-- group element in the document. We can be confident that it's the last-->
    <!-- one because we just added it with the previous do-remove-dest-attr-value-->
    <!-- action.-->
    <do-set-xml-attr expression="../modify[@class-name='Group' and last()]/modify-attr[@attr-name='Member' and last()]/remove-value[last()]/value[last()]" name="association-ref">
      <arg-string>
        <token-association/>
      </arg-string>
    </do-set-xml-attr>

    <!--Because we are within the context of a modify user operation we will use the -->
    <!--do-add-dest-attr-value in the same fashion as the do-remove-dest-attr-value-->
    <!-- was used previously. In like fashion, we will set the class-name to "Group".-->
    <!-- This will cause a modify group operation to be created as a sibling to the-->
    <!-- modify user operation we are working on (appearing at the end of the XDS-->
    <!-- document with the modify user operation).-->
    <do-add-dest-attr-value class-name="Group" name="Member">
      <arg-association>
        <token-local-variable name="DenyAccessGrpUNID"/>
      </arg-association>
      <arg-value type="dn">
        <token-src-dn/>
      </arg-value>
    </do-add-dest-attr-value>
    <!--We now have effectively added another modify group operation to the XDS doc.-->

    <!--Now we need to modify this latest modify group operation so that it-->
    <!-- contains an appropriate association-ref attribute. Because we now-->
    <!-- have multiple modify group operations within our XDS doc, we need-->
    <!-- to ensure that we place the association-ref attribute within the correct-->
    <!-- modify group operation. To do this we use a last() function, as in-->
    <!-- ../modify[@class-name='Group' and last()]. We know it's the last one-->
    <!-- because we just added it with the previous do-add-dest-attr-value-->
    <!-- action--> 
    <do-set-xml-attr expression="../modify[@class-name='Group' and last()]/modify-attr[@attr-name='Member' and last()]/add-value[last()]/value[last()]" name="association-ref">
      <arg-string>
        <token-association/>
      </arg-string>
    </do-set-xml-attr>
  </actions>
</rule>

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , , , ,
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

1 Comment

  1. By:cl_meyer

    very useful. I love Geoff’s articles

Comment