In Identity Manager 4.0 Novell has introduced a number of new features. There are four new driver configurations, two for applications (Salesforce.com and Sharepoint) and two for IDM itself to use, the Managed System Gateway driver and the Data Collection Service driver.

The Managed System Gateway driver is primarily used by the Reporting module to get information about users out of IDM and into the Reporting database. This is somewhat analogous to how the Identity Audit extension policies that were added to drivers are used to get Identity information into the Sentinel database.

As with many things in IDM 4, this is totally new stuff, and will take some time to get used too. You can read more about the changes between the various IDM versions in these articles:

• What has changed between Identity Manager versions - Part 1

• What has changed between Identity Manager versions - Part 2

• What has changed between Identity Manager versions - Part 3

• More on what's new in IDM 4

The Managed System Gateway (MSG) driver is one interesting critter. It is doing all sorts of funky and interesting things that it is worth discussing the low level functionality. After all, if you do not know what it is supposed to be doing, how would you know what it is not doing, when it is not working. Most connected system drivers are pretty traditional, that is an event comes out of the application of eDirectory, as an XDS document (which is what the shims job is, convert the applications event into XDS and convert XDS into things the application understands) which is then processed in the flow.

• In the first article Trying to understand the Managed System Gateway driver in IDM 4 - Part 1 of this series I started looking at how it builds up a cache of various interesting things. It stores them as driver scoped local variables. That means they are available while the driver is running. On every restart they need to be recalculated. There is the SERVER_INTERFACE, and DRIVER_DN variables that we talked about. These are in the Input Transform, in a series of policy objects.

• In the second article Trying to understand the Managed System Gateway driver in IDM 4 - Part 2 I started looking at one of the most audacious things I have ever seen a driver policy try to do! Read back another drivers DirXML Script policy, and figure out what it is doing! I was deeply astonished when I realized what it was trying to do! In fact my first reaction was, no way are they that crazy. Well apparently they are. I got through how they detect that a User is being managed, and how they detect that attribute based matching is happening.

• In the third article Trying to understand the Managed System Gateway driver in IDM 4 - Part 3 I looked at how the Matching rule is read to infer what attributes of the User was being matched upon. A very interesting and audacious approach!

• In the fourth article Trying to understand the Managed System Gateway driver in IDM 4 - Part 4 I discussed some short comings of that approach, and moved on to how the queries are handled from the various cache variables.

• In the fifth article Trying to understand the Managed System Gateway driver in IDM 4 - Part 5 I looked at some more examples of queries that the driver performs out of the cache and how the cache is dirtied if other changes are detected.

In this article I want to wrap up one last query.

The shim during initialization will read back the EntitlementConfiguration object from each driver, This is a new object that policy maintains in most supported drivers. This is needed for the mapping of entitlements to resources, as stored by the driver. John DaSilva and Volker Scheuber wrote an article explaining how to add such a policy to maintain this to your driver in: Convert Driver Entitlements to New RBPM 3.7 Resource Model

They discussed how to add the policy. I discussed what the policy is doing in this article: Converting Entitlements to Resources, more details

The gist of it, is that the driver maintains (by way of the policy John and Volker suggest) this EntitlementConfiguration DirXML-Resource object right under the driver object. The MSG driver needs to read that info back, and it does it with the following query, driver by driver.

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product build="4.0.0" instance="Managed System Gateway Driver" version="4.0.0">Identity Manager Managed System Gateway Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <query class-name="DirXML-Resource" dest-dn="\IDM4-IDV-01\system\driverset1\acme domain" scope="subtree">
      <search-class class-name="DirXML-Resource"/>
      <search-attr attr-name="CN">
        <value>EntitlementConfiguration</value>
      </search-attr>
      <read-attr attr-name="DirXML-Data"/>
    </query>
  </input>
</nds>

The returned XML in the DirXML-Data is Base64 encoded data:

[11/17/10 16:30:04.273]:Managed System Gateway Driver :
<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="4.0.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <instance class-name="DirXML-Resource" event-id="0" qualified-src-dn="O=system\CN=driverset1\CN=ACME Domain\CN=EntitlementConfiguration" src-dn="\IDM4-IDV-01\system\driverset1\ACME Domain\EntitlementConfiguration" src-entry-id="33803">
      <attr attr-name="DirXML-Data">
        <value timestamp="1290031576#36" type="octet">PGVudGl0bGVtZW50LWNvbmZpZ3VyYXRpb24gbW9kaWZpZWQ9IjIwMTAxMTE3MTAwNjE2Ij4KCTxlbnRpdGxlbWVudHM CgkJPGVudGl0bGVtZW50IGRhdGEtY29sbGVjdGlvbj0idHJ1ZSIgZG49IkNOPUV4Y2hhbmdlTWFpbGJveCxDTj1BQ01FIERvbWFpbixDTj1kcml2ZXJzZXQxLE89c3lzdGVtIiBwYXJhbWV0ZXItZm9ybWF0PSJpZG00IiByZXNvdXJjZS1tYXBwaW5nPSJ0cnVlIiByb2xlLW1hcHBpbmc9InRydWUiPgoJCQk8dHlwZSBjYXRlZ29yeT0ib3RoZXIgYWNjb3VudCIgaWQ9Im1haWxib3giIG5hbWU9Im1haWxib3giPgoJCQkJPGRpc3BsYXktbmFtZT4KCQkJCQk8dmFsdWUgbGFuZ0NvZGU9ImRlIj5Qb3N0ZmFjaDwvdmFsdWU CgkJCQkJPHZhbHVlIGxhbmdDb2RlPSJlbiI TWFpbGJveDwvdmFsdWU CgkJCQk8L2Rpc3BsYXktbmFtZT4KCQkJPC90eXBlPgoJCTwvZW50aXRsZW1lbnQ CgkJPGVudGl0bGVtZW50IGRhdGEtY29sbGVjdGlvbj0idHJ1ZSIgZG49IkNOPUdyb3VwLENOPUFDTUUgRG9tYWluLENOPWRyaXZlcnNldDEsTz1zeXN0ZW0iIHBhcmFtZXRlci1mb3JtYXQ9ImlkbTQiIHJlc291cmNlLW1hcHBpbmc9InRydWUiIHJvbGUtbWFwcGluZz0idHJ1ZSI CgkJCTx0eXBlIGNhdGVnb3J5PSJzZWN1cml0eSBncm91cGluZyIgaWQ9Imdyb3VwIiBuYW1lPSJncm91cCI CgkJCQk8ZGlzcGxheS1uYW1lPgoJCQkJCTx2YWx1ZSBsYW5nQ29kZT0iZGUiPkdydXBwZTwvdmFsdWU CgkJCQkJPHZhbHVlIGxhbmdDb2RlPSJlbiI R3JvdXA8L3ZhbHVlPgoJCQkJPC9kaXNwbGF5LW5hbWU CgkJCTwvdHlwZT4KCQkJPHBhcmFtZXRlcnM Cgk8cGFyYW1ldGVyIG1hbmRhdG9yeT0idHJ1ZSIgbmFtZT0iSUQiIHNvdXJjZT0iYXNzb2NpYXRpb24iLz4KCTxwYXJhbWV0ZXIgbWFuZGF0b3J5PSJ0cnVlIiBuYW1lPSJJRDIiIHNvdXJjZT0ic3JjLWRuIi8 CjwvcGFyYW1ldGVycz4KCTxtZW1iZXItYXNzaWdubWVudC1leHRlbnNpb25zPgoJCTxxdWVyeS14bWw CgkJCTxyZWFkLWF0dHIgYXR0ci1uYW1lPSJtZW1iZXIiLz4KCQk8L3F1ZXJ5LXhtbD4KCTwvbWVtYmVyLWFzc2lnbm1lbnQtZXh0ZW5zaW9ucz4KCTxxdWVyeS1leHRlbnNpb25zPgoJCTxxdWVyeS14bWw CgkJCTxyZWFkLWF0dHIgYXR0ci1uYW1lPSJvd25lciIvPgoJCQk8cmVhZC1hdHRyIGF0dHItbmFtZT0ic0FNQWNjb3VudE5hbWUiLz4KCQkJPG9wZXJhdGlvbi1kYXRhIGRhdGEtY29sbGVjdGlvbi1xdWVyeT0idHJ1ZSIvPgoJCTwvcXVlcnkteG1sPgoJPC9xdWVyeS1leHRlbnNpb25zPgo8L2VudGl0bGVtZW50PgoJCTxlbnRpdGxlbWVudCBkYXRhLWNvbGxlY3Rpb249InRydWUiIGRuPSJDTj1Vc2VyQWNjb3VudCxDTj1BQ01FIERvbWFpbixDTj1kcml2ZXJzZXQxLE89c3lzdGVtIiBwYXJhbWV0ZXItZm9ybWF0PSJpZG00IiByZXNvdXJjZS1tYXBwaW5nPSJ0cnVlIiByb2xlLW1hcHBpbmc9InRydWUiPgoJCQk8dHlwZSBjYXRlZ29yeT0ic2VjdXJpdHkgYWNjb3VudCIgaWQ9InVzZXIiIG5hbWU9ImFjY291bnQiPgoJCQkJPGRpc3BsYXktbmFtZT4KCQkJCQk8dmFsdWUgbGFuZ0NvZGU9ImRlIj5CZW51dHplcjwvdmFsdWU CgkJCQkJPHZhbHVlIGxhbmdDb2RlPSJlbiI VXNlcjwvdmFsdWU CgkJCQk8L2Rpc3BsYXktbmFtZT4KCQkJPC90eXBlPgoJCQk8cGFyYW1ldGVycz4KCTxwYXJhbWV0ZXIgbWFuZGF0b3J5PSJ0cnVlIiBuYW1lPSJJRCIgc291cmNlPSJyZWFkLWF0dHIiIHNvdXJjZS1uYW1lPSJBRERvbWFpblZhbHVlIi8 CjwvcGFyYW1ldGVycz4KCTxtZW1iZXItYXNzaWdubWVudC1xdWVyeT4KCQk8cXVlcnkteG1sPgoJCQk8bmRzIGR0ZHZlcnNpb249IjIuMCI CgkJCQk8aW5wdXQ CgkJCQkJPHF1ZXJ5IGNsYXNzLW5hbWU9IlVzZXIiIHNjb3BlPSJzdWJ0cmVlIj4KCQkJCQkJPHNlYXJjaC1jbGFzcyBjbGFzcy1uYW1lPSJVc2VyIi8 CgkJCQkJCTxyZWFkLWF0dHIvPgoJCQkJCTwvcXVlcnk CgkJCQk8L2lucHV0PgoJCQk8L25kcz4KCQk8L3F1ZXJ5LXhtbD4KCTwvbWVtYmVyLWFzc2lnbm1lbnQtcXVlcnk Cgk8cXVlcnktZXh0ZW5zaW9ucz4KCQk8cXVlcnkteG1sPgoJCQk8cmVhZC1hdHRyIGF0dHItbmFtZT0iZGlyeG1sLXVBQ0FjY291bnREaXNhYmxlIi8 CgkJCTxyZWFkLWF0dHIgYXR0ci1uYW1lPSJ1c2VyUHJpbmNpcGFsTmFtZSIvPgoJCQk8cmVhZC1hdHRyIGF0dHItbmFtZT0ic0FNQWNjb3VudE5hbWUiLz4KCQkJPG9wZXJhdGlvbi1kYXRhIGRhdGEtY29sbGVjdGlvbi1xdWVyeT0idHJ1ZSIvPgoJCTwvcXVlcnkteG1sPgoJPC9xdWVyeS1leHRlbnNpb25zPgoJPGFjY291bnQ CgkJPGFjY291bnQtaWQgc291cmNlPSJyZWFkLWF0dHIiIHNvdXJjZS1uYW1lPSJzQU1BY2NvdW50TmFtZSIvPgoJCTxhY2NvdW50LWlkIHNvdXJjZT0icmVhZC1hdHRyIiBzb3VyY2UtbmFtZT0idXNlclByaW5jaXBhbE5hbWUiLz4KCQk8YWNjb3VudC1pZCBzb3VyY2U9InNyYy1kbiIvPgoJCTxhY2NvdW50LWlkIHNvdXJjZT0iYXNzb2NpYXRpb24iLz4KCQk8YWNjb3VudC1zdGF0dXMgYWN0aXZlPSJmYWxzZSIgaW5hY3RpdmU9InRydWUiIHNvdXJjZT0icmVhZC1hdHRyIiBzb3VyY2UtbmFtZT0iZGlyeG1sLXVBQ0FjY291bnREaXNhYmxlIi8 Cgk8L2FjY291bnQ CjwvZW50aXRsZW1lbnQ Cgk8L2VudGl0bGVtZW50cz4KPC9lbnRpdGxlbWVudC1jb25maWd1cmF0aW9uPg==</value>
      </attr>
    </instance>
    <status event-id="0" level="success"></status>
  </output>
</nds>

The encoded content decodes too:

<entitlement-configuration modified="20101117100616">
	<entitlements>
		<entitlement data-collection="true" dn="CN=ExchangeMailbox,CN=ACME Domain,CN=driverset1,O=system" parameter-format="idm4" resource-mapping="true" role-mapping="true">
			<type category="other account" id="mailbox" name="mailbox">
				<display-name>
					<value langCode="de">Postfach</value>
					<value langCode="en">Mailbox</value>
				</display-name>
			</type>
		</entitlement>
		<entitlement data-collection="true" dn="CN=Group,CN=ACME Domain,CN=driverset1,O=system" parameter-format="idm4" resource-mapping="true" role-mapping="true">
			<type category="security grouping" id="group" name="group">
				<display-name>
					<value langCode="de">Gruppe</value>
					<value langCode="en">Group</value>
				</display-name>
			</type>
			<parameters>
	<parameter mandatory="true" name="ID" source="association"/>
	<parameter mandatory="true" name="ID2" source="src-dn"/>
</parameters>
	<member-assignment-extensions>
		<query-xml>
			<read-attr attr-name="member"/>
		</query-xml>
	</member-assignment-extensions>
	<query-extensions>
		<query-xml>
			<read-attr attr-name="owner"/>
			<read-attr attr-name="sAMAccountName"/>
			<operation-data data-collection-query="true"/>
		</query-xml>
	</query-extensions>
</entitlement>
		<entitlement data-collection="true" dn="CN=UserAccount,CN=ACME Domain,CN=driverset1,O=system" parameter-format="idm4" resource-mapping="true" role-mapping="true">
			<type category="security account" id="user" name="account">
				<display-name>
					<value langCode="de">Benutzer</value>
					<value langCode="en">User</value>
				</display-name>
			</type>
			<parameters>
	<parameter mandatory="true" name="ID" source="read-attr" source-name="ADDomainValue"/>
</parameters>
	<member-assignment-query>
		<query-xml>
			<nds dtdversion="2.0">
				<input>
					<query class-name="User" scope="subtree">
						<search-class class-name="User"/>
						<read-attr/>
					</query>
				</input>
			</nds>
		</query-xml>
	</member-assignment-query>
	<query-extensions>
		<query-xml>
			<read-attr attr-name="dirxml-uACAccountDisable"/>
			<read-attr attr-name="userPrincipalName"/>
			<read-attr attr-name="sAMAccountName"/>
			<operation-data data-collection-query="true"/>
		</query-xml>
	</query-extensions>
	<account>
		<account-id source="read-attr" source-name="sAMAccountName"/>
		<account-id source="read-attr" source-name="userPrincipalName"/>
		<account-id source="src-dn"/>
		<account-id source="association"/>
		<account-status active="false" inactive="true" source="read-attr" source-name="dirxml-uACAccountDisable"/>
	</account>
</entitlement>
	</entitlements>
</entitlement-configuration>

With IDM 4 and Packages, the rule that maintains this seems to have been tweaked a bit more, and is now included as part of a Package. Another example where fixing an issue after the driver is installed, was awkward before (see the steps John and Volker explain you need to do) but with a Package is now a piece of cake. If they realize they need more functionality or to fix a bug, just release an updated Package, and you can get customers to upgrade quite easily.

Included in that EntitlementConfiguration XML is a list of entitlements, the <entitlement> nodes. They include a DN, and a data-collection XML attribute as well. If the data-collection attribute is set to true, then the driver will look at it.

It then loops through the returned list of entitlements to read back the entitlements configuration. Here you see a query for a specific DN, that is class DirXML-Entitlement and returning the XmlData attribute:

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product build="4.0.0" instance="Managed System Gateway Driver" version="4.0.0">Identity Manager Managed System Gateway Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <query class-name="DirXML-Entitlement" dest-dn="system\driverset1\ACME Domain\ExchangeMailbox" scope="subtree">
      <search-class class-name="DirXML-Entitlement"/>
      <read-attr attr-name="XmlData"/>
    </query>
  </input>
</nds>

As before we get the XmlData (same basic idea as DirXML-Data attributes. I am not sure why they added a second such attribute to schema, but they are mostly functionally the same) base64 encoded.

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="4.0.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <instance class-name="DirXML-Entitlement" event-id="0" qualified-src-dn="O=system\CN=driverset1\CN=ACME Domain\CN=ExchangeMailbox" src-dn="\IDM4-IDV-01\system\driverset1\ACME Domain\ExchangeMailbox" src-entry-id="33782">
      <attr attr-name="XmlData">
        <value timestamp="1290031547#65" type="octet">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48ZW50aXRsZW1lbnQgY29uZmxpY3QtcmVzb2x1dGlvbj0idW5pb24iIGRlc2NyaXB0aW9uPSJUaGUgRXhjaGFuZ2UgTWFpbGJveCBFbnRpdGxlbWVudCBncmFudHMgb3IgZGVuaWVzIGFuIEV4Y2hhbmdlIG1haWxib3ggZm9yIHRoZSB1c2VyIGluIE1pY3Jvc29mdCBFeGNoYW5nZS4iIGRpc3BsYXktbmFtZT0iRXhjaGFuZ2UgTWFpbGJveCBFbnRpdGxlbWVudCI DQoJPHZhbHVlcyBtdWx0aS12YWx1ZWQ9InRydWUiPg0KCQk8cXVlcnktYXBwPg0KCQkJPHF1ZXJ5LXhtbD4NCgkJCQk8bmRzIGR0ZHZlcnNpb249IjIuMCI DQoJCQkJCTxpbnB1dD4NCgkJCQkJCTxxdWVyeSBjbGFzcy1uYW1lPSJtc0V4Y2hQcml2YXRlTURCIiBzY29wZT0ic3VidHJlZSI DQoJCQkJCQkJPHNlYXJjaC1jbGFzcyBjbGFzcy1uYW1lPSJtc0V4Y2hQcml2YXRlTURCIi8 DQoJCQkJCQkJPHJlYWQtYXR0ciBhdHRyLW5hbWU9IkRlc2NyaXB0aW9uIi8 DQoJCQkJCQkJPHJlYWQtYXR0ciBhdHRyLW5hbWU9IkNOIi8 DQoJCQkJCQk8L3F1ZXJ5Pg0KCQkJCQk8L2lucHV0Pg0KCQkJCTwvbmRzPg0KCQkJPC9xdWVyeS14bWw DQoJCQk8cmVzdWx0LXNldD4NCgkJCQk8ZGlzcGxheS1uYW1lPg0KCQkJCQk8dG9rZW4tYXR0ciBhdHRyLW5hbWU9IkNOIi8 DQoJCQkJPC9kaXNwbGF5LW5hbWU DQoJCQkJPGRlc2NyaXB0aW9uPg0KCQkJCQk8dG9rZW4tYXR0ciBhdHRyLW5hbWU9IkRlc2NyaXB0aW9uIi8 DQoJCQkJPC9kZXNjcmlwdGlvbj4NCgkJCQk8ZW50LXZhbHVlPg0KCQkJCQk8dG9rZW4tc3JjLWRuLz4NCgkJCQk8L2VudC12YWx1ZT4NCgkJCTwvcmVzdWx0LXNldD4NCgkJPC9xdWVyeS1hcHA DQoJPC92YWx1ZXM DQo8L2VudGl0bGVtZW50Pg==</value>
      </attr>
    </instance>
    <status event-id="0" level="success"></status>
  </output>
</nds>

The XmlData field base64 decodes to:

<?xml version="1.0" encoding="UTF-8"?><entitlement conflict-resolution="union" description="The Exchange Mailbox Entitlement grants or denies an Exchange mailbox for the user in Microsoft Exchange." display-name="Exchange Mailbox Entitlement">
	<values multi-valued="true">
		<query-app>
			<query-xml>
				<nds dtdversion="2.0">
					<input>
						<query class-name="msExchPrivateMDB" scope="subtree">
							<search-class class-name="msExchPrivateMDB"/>
							<read-attr attr-name="Description"/>
							<read-attr attr-name="CN"/>
						</query>
					</input>
				</nds>
			</query-xml>
			<result-set>
				<display-name>
					<token-attr attr-name="CN"/>
				</display-name>
				<description>
					<token-attr attr-name="Description"/>
				</description>
				<ent-value>
					<token-src-dn/>
				</ent-value>
			</result-set>
		</query-app>
	</values>
</entitlement>

This is how entitlement definitions are stored, in case you never looked. You can see it is based on a query, which is functionally a dynamic group. A dynamic group is an group whose membership is defined by an LDAP query. In this case, the membership of the entitlement is defined by an XDS query.

Then it parses out the Query XDS that was in the entitlement definition. This is useful to the Reporting module, as it can revalidate the entitlements if it needs too, and like the matching rule, potentially validate why objects without the entitlement did not get it.

<nds dtdversion="2.0">
	<input>
		<query class-name="msExchPrivateMDB" scope="subtree">
			<search-class class-name="msExchPrivateMDB"/>
			<read-attr attr-name="Description"/>
			<read-attr attr-name="CN"/>
		</query>
	</input>
</nds>

In the Publisher Event Transform policy set, the last policy object is named NOVLIDMMSGWB-pub-etp-DispatchAccountsQuery and this does something somewhat different. It uses the same data delivery model, of adding the payload to the <operation-data> nodes of the document, but it does not read that out of cache variables, rather it gets the request and does an appropriate query, and builds a result to be returned.

This is an interesting example of doing the work in policy instead of in the driver shim, since really the driver shim should have done the work, and just made the appropriate queries needed. However, in discussions with one of the people involved in this driver, it seems that they recognized this was going to be a driver in flux, and doing tricky things, and with the advent of Packages, it would actually be easier to update a configuration in a Package than a binary shim file. Thus you see a number of things in this driver configuration that properly might have been done in the shim, but are being done instead in policy. Not that I am complaining, as this is quite interesting learning how they approached this issue.

This rule sees an incoming MS_ACCOUNT_INFO query for driver (Specified in the dest-dn) and an association value (a GUID) but that is not really what it wants. The real query it wants is to find the user with the association value whose GUID is the query docs association value for the driver whose DN is provided. Sort of an offhanded way to ask for some specific data.

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product build="4.0.0" instance="Managed System Gateway Driver" version="4.0.0">Identity Manager Managed System Gateway Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <query class-name="MS_ACCOUNT_INFO" dest-dn="\IDM4-IDV-01\system\driverset1\acme domain" scope="subtree">
      <search-class class-name="MS_ACCOUNT_INFO"/>
      <association>eb647c235a7f2343854e31134ba3f217</association>
      <read-attr/>
    </query>
  </input>
</nds>

You can see the straightforward query document, for what looks like a search for a Driver object with a specific association value.

The NOVLIDMMSGWB-pub-etp-DispatchAccountsQuery policy looks at that query, and does a better query for the User, whose DirXML-Associations attribute matches what this query really wants. We can see that the three components of the DirXML-Association are set to 1 for nameSpace, which means the state is associated. The volume component is set to the driver DN provided, which is how the DirXML-Association indicates for which driver the specific association applies. The path component is set to the provided GUID value that came as the association node in the query document.

It does this by picking out the pieces from the initial query document to get the information needed to perform the following Query token request:

<do-set-local-variable name="accInfo" scope="policy">
	<arg-node-set>
		<token-query class-name="User">
			<arg-match-attr name="DirXML-Associations">
				<arg-value type="structured">
					<arg-component name="nameSpace">
						<token-text xml:space="preserve">1</token-text>
					</arg-component>
					<arg-component name="volume">
						<token-local-variable name="drvDn"/>
					</arg-component>
					<arg-component name="path">
						<token-local-variable name="accountAssociation"/>
					</arg-component>
				</arg-value>
			</arg-match-attr>
			<arg-string>
				<token-text xml:space="preserve">GUID</token-text>
			</arg-string>
			<arg-string>
				<token-text xml:space="preserve">Dirxml-Accounts</token-text>
			</arg-string>
		</token-query>
	</arg-node-set>
</do-set-local-variable>

What is neat is that it did not need to do any XPATH to do this, as the driver DN was available via the destination DN token. The Association() token reads back the association value being passed in.

This asks to return the GUID of the located object, and the DirXML-Accounts data. DirXML-Accounts is an attribute added by the Identity Audit package, and was part of Sentinel. Prior to Packages it was added to the IDM 3.6 and 3.6.1 driver configurations, via rules provided in a Library and linked into many driver configurations, to hold a more readable form of what an object has associated with it, for use in Sentinel. The Identity injection component of Sentinel is quite powerful and somewhat unique. Usually in an SEIM (Secure Event Information Management) product, you work at the level of IP's and possibly services. With Sentinel, not only do you try to correlate events that look suspicious from a networking or otherwise perspective, if you can identify a relevant user name then Sentinel can identify which other accounts this user has, so you might want to proactively lock down all the compromised users accounts as soon as one is compromised. Very powerful stuff.

However, like the Resource to Entitlement mapping added into the Roles Based Provisioning Module 3.7 (RBPM) which at some level is mostly meant as an abstraction layer to let you give an Entitlement a pretty name. As a friend said, Entitlements are for computers, Resources are for people. Here too, while the data is mostly stored in the DirXML-Associations value, it sure isn't pretty. Thus some additional policy has been added in the later configurations, that would have been so much easier if we had Packages earlier, that maintains the DirXML-Accounts attribute. It is this attribute that Sentinel uses, and now we see that the MSG driver also uses it. Which is nice to see them leveraging existing attributes instead of adding new ones of their own.

The query token shown above, generates this XDS Query doc:

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="4.0.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <query class-name="User" scope="subtree">
      <search-class class-name="User"/>
      <search-attr attr-name="DirXML-Associations">
        <value type="structured">
          <component name="nameSpace">1</component>
          <component name="volume">\IDM4-IDV-01\system\driverset1\acme domain</component>
          <component name="path">eb647c235a7f2343854e31134ba3f217</component>
        </value>
      </search-attr>
      <read-attr attr-name="GUID"/>
      <read-attr attr-name="Dirxml-Accounts"/>
    </query>
  </input>
</nds>

Below is the returned sort of document you should get, however I cannot find a sample of trace showing that includes how DirXML-Accounts would look in the returned document. Darn. That would have been useful to pick apart.

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="4.0.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <instance class-name="User" event-id="0" qualified-src-dn="O=data\OU=users\CN=ccentral" src-dn="\IDM4-IDV-01\data\users\ccentral" src-entry-id="33439">
      <attr attr-name="GUID">
        <value timestamp="1287434878#2579" type="octet">f8FZpifW0ELblX/BWaYn1g==</value>
      </attr>
    </instance>
    <status event-id="0" level="success"></status>
  </output>
</nds>

As it happens, you should note that the GUID is returned as an octet string attribute (The type="octet" XML attribute of the <value> node is where you see that), which means it is base 64 encoded data. However, just base 64 decoding it does not actually help, as that is not the format you want it in. It turns out there are at least 3 ways different parts of Identity Manager display the GUID in translated form. There is the way the Active Directory driver does it when storing the Active Directory GUID in the DirXML-Associations path component, the way the eDirectory driver stores the association value, and the way Entitlements use and expect it. Reading through the policy we can see that the GUID gets converted with the XPATH:

es:guid2string($current-node/attr[@attr-name="GUID"]/value/text()) 

This ECMA Script function comes from the Advanced Java Class (AJC) that is one of the common base packages now included. The AJC was originally a Java class (as the name would have you believe) that the Novell Consulting guys relied on, before many functions were added as tokens to IDM. It has all sorts of interesting and useful functions like time conversions, and logging to files. It was ported to ECMA which was a little easier, as a Java class needs to be copied, but an ECMA Script Resource can be part of the configuration (old style or new Packages). Now it is part of one of the base packages that almost all the other packages require. If you are interested in learning how to use ECMA Script in Identity Manager, I would recommend looking at the AJC library as there are so many useful examples.

This function, guid2string converts it to the appropriate format, which I think is the Entitlement way of looking at GUID values.

As is usual in this driver, the payload response is added as <operation-data> even though it technically almost could just be returned. Well sort of. The policy stripped out the association value from the document, and this is no longer the same event that came in, thus the engine would not be able to properly identify it as connected with the original query:

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product build="4.0.0" instance="Managed System Gateway Driver" version="4.0.0">Identity Manager Managed System Gateway Driver</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <query class-name="MS_ACCOUNT_INFO" dest-dn="\IDM4-IDV-01\system\driverset1\acme domain" scope="subtree">
      <search-class class-name="MS_ACCOUNT_INFO"/>
      <read-attr/>
      <operation-data api-name="MS_ACCOUNT_INFO">
        <instance class-name="MS_ACCOUNT_INFO" src-dn="O=data\OU=users\CN=ccentral">
          <attr attr-name="idv.account.guid">
            <value type="string">7FC159A6-27D6-d042-DB95-7FC159A627D6</value>
          </attr>
          <attr attr-name="idv.dirxml.account"/>
        </instance>
      </operation-data>
    </query>
  </input>
</nds>

As usual, this gets converted to a normal XDS query response:

<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="4.0.0">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <instance class-name="MS_ACCOUNT_INFO" src-dn="O=data\OU=users\CN=ccentral">
      <attr attr-name="idv.account.guid">
        <value type="string">7FC159A6-27D6-d042-DB95-7FC159A627D6</value>
      </attr>
      <attr attr-name="idv.dirxml.account"/>
    </instance>
  </output>
</nds>

With that last example, I think that exhausts the extent of this driver. It certainly is an interesting driver, and I hope you have enjoyed walking through it with me.

I think the next interesting such exersize needs to be performed on the Data Collection Service driver. Looking at it quickly I see that the filter includes pretty much every object and every attribute you might be interested in reporting on. Of course how it handles and manages that data will be the interesting part! But first I need to gather some trace examples to work with.