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:

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 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.

Series Navigation<< Trying to understand the Managed System Gateway driver in IDM 4 – Part 5
0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...

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.

Leave a Reply

No Comments
geoffc
By: geoffc
Mar 11, 2011
4:23 pm
Reads:
1,451
Score:
Unrated