What do the various IDM driver object attributes represent Part 1:

In Novell Identity Manager, there are a couple of important objects that contain the objects, and have interesting attributes available. This article will consider some of the available object classes and attributes and their relevance.

• DirXML-Policies

• DirXML-NextTransformation

• DirXML-ACT2

• DirXML-ApplicationSchema

• DirXML-ConfigManifest

• DirXML-ConfigValues

• DirXML-Filter

First up we have a Driver Set object (object class of DirXML-DriverSet) that can contain DirXML-Driver objects.

The DirXML-Driver object has two channel objects, of object class DirXML-Subscriber and DirXML-Publisher.

New object classes have been added that can be contained in these various classes. Like Library objects that were added around Identity Manager 3.5 timeframe, and are of object class DirXML-Library.

The original objects that started us all off with IDM way back when, are still the DirXML-Rule and Stylesheet objects. Both objects have an XMLData attribute, where the XML of the policy or stylesheet is stored. I think they added DirXML-Stylesheet (inheriting from StyleSheet) at some point. I am not sure of the history of this change.

There both also have the DirXML-NextTransformation attribute, that is how policies were linked prior to IDM 3.5. In IDM 3.0, and below the Policy and Stylesheet objects were linked via these attributes, which made reusing a policy object difficult. After all while I could link to this object, it would still contain links to the next object in the chain.

That is, say in the Subscriber Create policy set, I wanted to have three different policy objects. The DirXML-Subscriber object has an attribute DirXML-CreateRule which is DN (distinguished name, which means it is an efficient way to reference another object) syntax that points at the first rule in the chain. Then that rule has an attribute DirXML-NextTransformation that points at the next rule in the chain, and so on and so forth.

If I want to reuse a policy object that is not the last one in a chain, then linking to it, say in the Publisher Create Rule as well will bring with it any later policy objects in the chain.

This was resolved in IDM 3.5 and higher, which is why the "Linkage model" needs to be updated when you upgrade from earlier versions to 3.5 and higher.

In IDM 3.5 and higher there was a schema update, adding a multi valued attribute DirXML-Policies which is Typed Name syntax, which is an interesting syntax. It has a DN, and two 32 bit integers. This attribute is added to the available attributes on the DirXML-Driver and DirXML-DriverSet object classes.

The DN component (called originally enough, dn) references the object linked in, be that a DirXML-Rule, a DirXML-Stylesheet, a Schema Map (also a DirXML-Rule object) or whatever. Then they defined for the second integer component (named interval) a numerical value for each stage in Fishbone view. I am not sure I have seen all the values defined, but they are reasonably easy to derive from an example case. Take a driver configuration, and name a single rule in each policy set with a descriptive name, then go look at the DirXML-Policies attribute.

Then the other integer component, (named level) is used to indicate the ordering within the Policy Set.

This is a nice model, as new features can be added by just allocating the next free value to the new feature. There is also no real limit on the number of policy objects you can link in this fashion.

It also means if you feel like it, you can read back what policies are associated with a particular driver, while in IDM Policy. I would have said there is no need for this, but in the Managed System Gateway driver, part of the pair of drivers (The other is the Data Collection Service Driver) that the Reporting module in IDM 4 needs, they actually DO read back the DirXML-Policies attribute to find the Matching rules, parse them, looking to derive what is being matched on, for each driver. When I first read that, I thought it was crazy, but it seems to work. You can read more about the Managed System Gateway driver and all the wild and crazy things it does in this series of articles:

Managed System Gateway Driver:

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 1

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 2

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 3

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 4

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 5

• Trying to understand the Managed System Gateway driver in IDM 4 - Part 6

Data Collection Service Driver:

• Data Collection Service Driver Walkthrough - Part 1

• Data Collection Service Driver Walkthrough - Part 2

• Data Collection Service Driver Walkthrough - Part 3

• Data Collection Service Driver Walkthrough - Part 4

• Data Collection Service Driver Walkthrough - Part 5

• Data Collection Service Driver Walkthrough - Part 6

• Data Collection Service Driver Walkthrough - Part 7

• Data Collection Service Driver Walkthrough - Part 8

When you look at an iManager driver export, you can see how the data is formatted as well, here is a single example.

<policy-linkage>
	<linkage-item dn="NOVLAUDTENTC-itp-SendEntitlementsEvents.ADDriver.Driver Set 2.null" order="1" policy-set="1" policy-set-name="Input"/>
	<linkage-item dn="NOVLADENTEX-itp-InitEntitlementConfigurationResource.ADDriver.Driver Set 2.null" order="2" policy-set="1" policy-set-name="Input"/>
	<linkage-item dn="NOVLADDCFG-itp-SubscriberUserAdd.ADDriver.Driver Set 2.null" order="3" policy-set="1" policy-set-name="Input"/>
</policy-linkage>

You can see that there are three Input Transform rules listed, and they are all in policy-set 1, which is the Input Transform, but the ordering is set via the order= XML attribute, and I copied in an example of one to three.

The actual syntax and format in the attribute is slightly different but it is easier to see and understand in the iManager configuration file. (You can of course generate such a file from Designer, regardless of the fact I keep calling it the iManager configuration file. Just export to a Configuration file, instead of the project to a ZIP archive).

The DirXML-ACT2 attribute appears to hold the licensing information. That is, when you activate your IDM instance (you get 90 days to try it for free, then the engine and drivers shut down until you add an activation credential) the license code is stored in this attribute.

DirXML-ApplicationSchema is an interesting attribute. If your driver implements the getSchema() function, which the Active Directory, eDirectory, and I am sure others do support, then the returned schema info from the first driver startup will be stored in this attribute as an XML document. If in iManager or Designer you issue the Refresh Application Schema command, the driver will restart and it will issue the getSchema() function call at that restart. When you watch an Active Directory driver startup for the first time, you can see it takes a while as the entire AD schema is read in. It never was entirely clear what the real purpose for this attribute is, it would seem it would be useful in a merge case to decide if an attribute is multi valued in the connected system, to know how to approach merging the values, but I am not sure that was ever really implemented. There is a great simple piece of policy that takes advantage of the information in DirXML-ApplicationSchema for the Active Directory driver, to try and flatten out multi valued attributes in eDirectory heading towards Active Directory and you can read more about it here. Generic Single-valued Schema Enforcement

An example from an iManager configuration file, which is basically have it looks in the attribute.

<application-schema>
	<schema-def dn-format="ldap">
		<class-def class-name="user" container="true">
			<attr-def attr-name="accountExpires" multi-valued="false" type="int"/>
			<attr-def attr-name="accountNameHistory" type="string"/>
		</class-def>
	</schema-def>
</application-schema>

I trimmed the example down for brevity, but you get the idea. As you can see, attributes are flagged with an XML attribute multi-valued which if false, means you ought to flatten any modifies with more than one value, which is what the article I quoted does.

DirXML-ConfigManifest contains XML that describes the features of the driver. If you configured an eDirectory driver for Password Sync V 1.0, then your DirXML-ConfigManifest would be missing important information, that the Password Management (in Designer, its called Server Variables in iManager) uses to decide if the driver supports password sync in any particular direction.

I recently went through the exercise of upgrading a Password Sync 1.0 eDirectory driver to support the use of Universal and Distribution passwords. Had to find another driver with a proper manifest, copy the XML in, link in the Publisher and Subscriber channel rules in the Command Transform that are needed, and then adjust the filter. You can read more about how those rules work in this pair of articles:

• Password Transformation Rule Sets

• Password Transformation Rules in the Publisher Channel

In IDM 3.6 and up there is more payload in the manifest, as it is used to describe how this driver should respond to the Health Monitoring Job that was introduced in IDM 3.6 (and if you are considering it while running IDM 3.6 make sure you upgrade to 3.6.1 as there is a bad memory leak in this feature that 3.6.1 patches).

A sample manifest, trimmed down is below. The first part that talks about password compatibility is what I was referring too above. The original Password Sync 1.0 driver configurations (Which is syncing the Private Key and Public Key (RSA Key pairs) between trees) did not have these values set. Thus to enable Password Sync 2.0, you need to tell the driver in the manifest that it has the ability now. Then below it is the <health-config> node, which shows what is a red, green, or yellow state for the driver. (I trimmed it down for brevity but there was more).

<manifest>
<DirXML-DriverId>AD</DirXML-DriverId>
<!-- password capabilities -->
<!-- supports publisher modify password notification when Active Directory password changes -->
<capability name="password-publish"/>
<!-- supports subscriber password and modify password commands to change Active Directory password -->
<capability name="password-subscribe"/>
<!-- supports subscriber verify password commands by attempting a login to Active Directory -->
<capability name="password-check"/>
<health-config>
<red>
<actions>
<generate-event id="1230" level="log-info">
<event-arguments>
<event-argument name="value" value="3"/>
<event-argument name="value3" value="1"/>
<event-argument name="text2" value='Driver entered "Red" state'/>
</event-arguments>
</generate-event>
</actions>
</red>
</health-config>
</manifest>

Next attribute on the driver object is DirXML-ConfigInfo. This uses the same DTD as the Global Configuration Variables (GCV) do. Thus all the fun you can have with the various GCV types, and grouping and headers, can be used in the driver configurations. The difference is there is no 'add' or 'edit' button in the Configuration user interfaces, but you can edit the XML to make changes. If you prefer a user interface to writing XML by hand, this means you just make a GCV that you want, edit the XML view, copy the XML text, and paste it into the Configuration tab. There are some minor differences as there are tags for each channel so where in the XML you place makes a difference, but not too much. You can read more about the GCV syntax types in these articles:

• Explaining GCVs - Part 1

• Explaining GCVs - Part 2

• Structured Global Configuration Values in IDM

Sometimes, like in the Active Directory driver, to add support for new features, you may need to add an option by hand. Like for Exchange 2007 and then later Exchange 2010 support. In the GroupWise driver, there was a need for a while to edit one of the values to add version 8 as an allowed version. In the SOAP driver there is a patch that allows support for query-ex if you want it, but to use it, you have to add a configuration value by hand in the XML.

I am not certain what the DirXML-DriverCacheLimit attribute is used for.

The DirXML-Filter is where the filter information is stored. This is different than the other policy sets and schema mappings, as those are stored in standalone objects, where as the Filter is an attribute on the object.

This posed the developers with a conundrum, when they were designing Packages for Designer in IDM 4. The notion of Packages was to break down each driver configuration into individual, mostly independent bundles of code that can be added or removed separately. They needed to extend the way GCV's are stored, since those too are a single attribute on the driver, and they managed quite nicely by making a GCV object that can be linked into a Driver, just like ECMA Resource objects get linked in. . They also faced the same issue with Filters.

Here is an example of the filter from an iManager configuration file, but it is stored on the driver, in the DirXML-Filter object in pretty much the same format.

<driver-filter-xml>
	<filter>
		<filter-class class-name="User" publisher="sync" publisher-create-homedir="true" publisher-track-template-member="true" subscriber="sync">
			<filter-attr attr-name="nspmDistributionPassword" merge-authority="default" publisher="ignore" publisher-optimize-modify="true" subscriber="notify"/>
	</filter>
</driver-filter-xml>

However, they did not solve the Filter issue the same way they did for GCV values. I am sure there is a technical reason for it, but they had to use a slightly less flexible approach for the initial release of Packages in IDM 4.

The way it was described to me is that filters are mostly additive. That is, it is easy for a Package to add a filter. It is not so easy to remove values from the filter, especially after a person has started mucking about by hand. For now they are mostly just supporting simple addition and removal. I guess it was too much of a code change, and probably a shim side change to support it. (If they had to modify every shim to support it, you can see why that is a much bigger task to deal with). I am not sure why this is different than GCV's but apparently it was.

Well that brings us to the end of this article. I think there is lots more to talk about, so stayed tuned for the next part of this series.