DirXML-Associations nameSpace wildcard magic number

When constructing a query for the DirXML-Associations attribute, I wanted to find a specific entitlement value.  In order to construct the query, I need all 3 parts of the structured attribute, which are nameSpace, volume, and path.  Volume is the DN of the entitlement object.  Path is the XML value of the entitlement.  nameSpace is the status of the entitlement as it it relates to the user.  The nameSpace attribute will NOT allow you to use a simple "*" wildcard.  Turns out, there is a "Magic Number" that is used in place of the wildcard.  That magic number is 4278190086.  Took quite a bit of Googling to find this.

Now, I tried the same thing on the nrfEntitlementRef attribute for nrfResource objects and it does NOT work - the error returned looks like:

<status level="error">Code(-9053) One or more errors occurred while
processing a query: Code(-8009) Error processing &lt;search-attr>:
java.lang.NumberFormatException: For input string: "4278190086".</status>

To work around, I simply did two queries and stuffed their values in the same nodeset (in DirXML - I've been told the magic number works for LDAP calls).  It seems the only values it gets for nameSpace are 0 and 1.  When setting my local variable nodeset - I simply included the same query with both values.  If I find a different value, I'll be sure to update this blog post.

Novell IDM Syntax Violation Errors

I was recently working on a driver.  I had finished the driver and everything was working great.  I then started getting the following errors on my driver:

Code(-9010) An exception occurred: novell.jclient.JCException: createEntry -613 ERR_SYNTAX_VIOLATION

After yanking out some of the hair on my scalp, I took two traces, one of a user that was created successfully, and one of a user that kicked back this error.  I looked at the XML document after all the driver logic was finished just before it tried to create the account.

What I found was there were very few differences (I hope not), but what ended up standing out is that in one of the traces, the user had a blank value for their Title attribute, and looked similar to this:

<add-attr attr-name="Title">
   <value type="string"/>
</add-attr>

Why is this significant?  Because if you look at the schema for eDirectory, the attribute Title is sized, with a minimum length of 1 character, meaning a blank attribute is not valid.

The resolution for this was simple.  I found all attributes that had sizing restrictions on them, then simply did a check and stripped them out if they had a blank value.  Here is what the Title attribute sample looked like:

<rule>
   <description>Strip Title if blank</description>
   <comment xml:space="preserve">If title is a blank value, strip it so it doesn't cause a syntax violation.</comment>
   <conditions>
      <and>
          <if-class-name mode="nocase" op="equal">User</if-class-name>
          <if-op-attr mode="nocase" name="Title" op="equal"/>
       </and>
   </conditions>
   <actions>
       <do-strip-op-attr name="Title"/>
   </actions>
</rule>

Once this was done all of the errors disappeared!

Sharing Policies between Drivers in Novell IDM

Working with Novell IDM to integrate an HMS Payroll System hosted on an AS400 system in a DB2 database.  The customer has approximately 120 of these databases that need to be interfaced.  In order to accomplish this, I need to create 120 separate JDBC drivers.

I was able to architect and implement the drivers in such a way that all of the policies are identical.  The only differences between them are the connection parameters and some GCV's.  With all of the policies identical, I wanted to deploy them in such a way that updates to the drivers are easier than duplicating the modification 120 times.

By creating a new Library container within the driverset, I was able to reference the policies within the drivers from the shared Library.  This allows all of the drivers to subscribe to the same policy and XSL objects.  When an update needs to occur for the 120 drivers, the policy in question is updated in the library, then all of the drivers are restarted. 

To expedite the process of restarting all of the drivers, I simply restart DirXML on the servers hosting the drivers.  This will force a restart of these drivers, so long as they are set to automatic startup.

Please note that the Filter cannot be shared as it must exist on the driver object, so changes to filter will still require changing all 120 drivers individually.