In part one of this discussion, we talked about using Global Configuration Variables (GCV's) to replace literal strings in a common driver implementation. In the first article we discussed the Subscriber channel. In this article the goal will be to finish up by working through the Publisher channel set of rules.

There are many reasons to go through this effort. The simplest is that if you ever were to rename your tree structure in either tree, updating the rules to handle that becomes a piece of cake. The more common reason is if you are developing in a test tree, and perhaps the tree structure is not identical, then when you are ready to roll out to production, it is significantly easier to update all the location names if you just change the GCV.

GCV's and Scoping

As a reminder, here are our defined Global Configuration Variables from the previous article, to refresh your memory. First off we need our eDirectory container location:

<definition display-name="Container in eDirectory that holds active Users (Format is acme\users\active backslash notation)." name="acmeActiveeDirContainer" type="string">
  <description>Global variable to define references to the eDirectory container that Active users will be found in.</description>
    <value>acme\Users\Active</value>
</definition>

Next, we need to FQDN of our Active Directory Users locations:

<definition display-name="FQDN name where AD users are found (ou=Users,dc=acme,dc=com syntax):" name="acmeActiveDirFQDN" type="string">
  <description>GCV that defines where to locate and place users in Active Directory. Use LDAP syntax to specify the FQDN of the location.</description>
  <value>ou=Active,ou=User,dc=Acme,dc=com</value>
</definition>

The third GCV we need is for UPN Name. Here is an example:

<definition display-name="UPN Name for Active Directory (in DNS format, acme.com for example):" name="acmeActiveDirUPNName" type="string">
  <description>GCV that defines the UPN Name formatting in the target AD system.</description>
  <value>acme.com</value>
</definition>

Walking through the Publisher channel, (at the top of the fishbone diagram in Designer, and from the left-hand side in iManager) the Input Transformation rule does not have anything we are concerned about.

In the Publisher Event Transformation, we probably want to scope the driver so that it only considers users that are coming from our specific subtree. An example rule to do that might be something like this:

<rule>
  <description>[acme] Scope the driver to the GCV of the Users container</description>
  <comment xml:space="preserve">We probably do not want the driver taking users from everywhere in the AD tree. Lets scope it to the container and down that we care about.</comment>
  <comment name="author" xml:space="preserve">Geoffrey Carman</comment>
  <comment name="version" xml:space="preserve">1</comment>
  <comment name="lastchanged" xml:space="preserve">Mar 16. 2008</comment>
  <conditions>
    <and>
      <if-class-name mode="nocase" op="equal">User</if-class-name>
      <if-src-dn op="not-in-subtree">~acmeActiveDirFQDN~</if-src-dn>
    </and>
  </conditions>
  <actions>
    <do-veto/>
  </actions>
</rule>

Note that we test this to be sure it is a User object class; if we did not, we might veto the driver start event. We also might want to consider scoping it a little further, perhaps only looking at operations of add or modify, but this should be sufficient for most cases.

Publisher Matching Rule

On to the Publisher Matching rule. This one is just as complex as in the Subscriber channel and has at least four places to change.

1. Change the condition test on the first rule "Find a matching unassociated object in the Identity Vault" from:

<if-src-dn op="in-subtree" xml:space="preserve">cn=user,dc=test,dc=com</if-src-dn>

to:

<if-src-dn op="in-subtree">~acmeActiveDirFQDN~</if-src-dn>

2. In the rule named "match users based on NT logon name" change the line from:

<token-text xml:space="preserve">acme\users</token-text>

to:

<token-global-variable name="acmeActiveeDirContainer"/>

3. In the rule called "match users based on full name" change the line from:

<token-text xml:space="preserve">acme\users</token-text>

to:

<token-global-variable name="acmeActiveeDirContainer"/>

4. In the rule named "match everything else" change the condition:

<if-src-dn op="in-subtree" xml:space="preserve">cn=user,dc=test,dc=com</if-src-dn>
to:
<if-src-dn op="in-subtree">~acmeActiveDirFQDN~</if-src-dn>

and the following line in the Arg DN of:

<token-text xml:space="preserve">acme\users</token-text>

to:

<token-global-variable name="acmeActiveeDirContainer"/>

Moving along, we come to the Publisher Create rule. In this case, we do not have anything to do here.

Publisher Placement Rule

Next is the Publisher Placement rule. In this case, we need to change one line, but it is worth explaining what the driver is doing here.

In a mirrored placement, we are leveraging the work already done in the matching rule. In the Publisher matching rule, it used a token, Unmatched Source DN, to set an operation property. This property held the DN to the value of the rest of the DN, after you take out the Subtree that we specified.

For example, let's take a user "CN=BSmith,OU=Acct,OU=Texas,OU=US,ou=Active,OU=Users,dc=acme,dc=com" and our GCV defined as above. The Unmatched source DN would be a fragment of "Ou=Acct,OU=Texas,OU=US". That would be converted to slash notation to append to our GCV value (once we change it from using a literal string) to generate the operation destination DN.

Thus in the rule named "placement for all objects" we change:

<token-text xml:space="preserve">acme\users</token-text>

to:

<token-global-variable name="acmeActiveeDirContainer"/>

Finally, we are left with the Publisher channel Command Transformation set of policies, and it turns out there is not much to do in these policies at all.

There you have it: a common driver set configuration modified to use Global Configuration Values instead of literal text strings. Using this, you could in priniciple import it for any environment and just change the values of the GCVs that we defined and be ready to go.

Some of the Novell Identity Manager drivers as shipped do this already. The Linux-Unix bidirectional driver takes the values you enter at the time you import the driver and answer the prompts, and rather than write the literal text string into all the places in the policy that we just saw, it just sets the GCV values. The rules come predefined using the GCV references.

Other drivers are moving their default configuration to this model. As the Resource Kit for Identity Manager gets more usage and more people are exposed to it, this will be the direction of the future.

Attached you will find the completed driver export from both these articles, with the Subscriber and Publisher channel modifed as described in the articles.