The release of IDM 4 SP2 will include a new eDirectory driver that does not need a full install of Identity Manager in both trees, rather just a changelog plugin will be needed on the connected eDirectory.

This is something people have wanted for a long time, and should be quite interesting.

In the first article in this series I discussed the packages used to deliver this driver, and then some of the configuration settings.

In this article I would like to start looking at some of the GCVs (Global Configuration Variables) that come with the driver, and then on to policy walkthroughs.

There 5 GCV objects (plus the driver itself for number 6) so lots of GCVs and I may defer some of them.

The driver itself is where the eDirectory Base container is set. This is used in a <gcv-ref> node in the driver configuration, so that you cam set it once in the GCV prompts, and use it in both places. I had discussed the various GCV types in a series of articles, and at the time had not understood what the point of this GCV type was, but this is a nice example. You can read more about the other GCV types in these articles:

• Explaining GCVs - Part 1

• Explaining GCVs - Part 2

The shim needs the value, in its configuration, since it will be sent probably as a base container for the search or else to notify the changelog feature where to monitor. But policy needs it for some scoping as well. This way the installer enters the information once, and in fact if you change it in the GCV, then the changed value is reflected in the Configuration value as well. What is interesting is that for the Driver GUID they handled it slightly differently. There, as a hidden configuration value (open the XML view, and search for hide="true" in any configuration XML) they used the built in auto GCV as:

<definition display-name="Driver GUID:" hide="true" name="driverGUID" type="string">
	<description>Specify the Driver GUID.</description>
	<value>~dirxml.auto.driverguid~</value>
</definition>

Which would have worked here as well, but I suppose this is a prettier solution, though it leaves ambiguity as to where the value should be set, though it does seem to reflect the change in both directions, so I guess that is not so bad. Maybe I would be happier if it was somehow flagged as being a reference to each other in both places.

The Password Synchronization GCV tab is the usual for all base drivers, and you should not modify the values directly here, instead use the Password Synchronization page which represents the values in a simpler fashion.

Default Configuration has two options, Subscriber and then Publisher Placement types. There are two options for each flat and mirrored.

These are nice base configurations but only work when there is a single root container from which to place users or to the mirror the structure from. When you have a paraphyletic tree structure you need to synchronize it does not work as well.

Managed System Information is an interesting GCV object, this is the MSysinfo object where an Input Transform rule regenerates the bottom half every driver start. You can read more about how this is used in Reporting in the following series of articles on the Managed System Gateway driver:

• Series: Trying to understand the Managed System Gateway driver in IDM 4

Account Tracking is a complicated topic, and basically is used to populate the DirXML-Accounts attribute on a user for sending to Sentinel so that identity information will be made available in Sentinel. The key thing it tries to do (in a way to complicated fashion I believe) is to track each system a user has an active account in.

The GCV's are basically here to provide a realm (what is the name of the system), what counts as a user in the connected system (since the rules fire in the Input Transform, and thus still in the application name space before the schema map), and what is the attribute that indicates active or inactive.

The Entitlements GCV object is used to control the user of Entitlements. There are group and user entitlements supported, and a control over whether the loss of an entitlement is a delete or a disable. Advanced Settings have a number of settings related to how reporting and Roles can ultimatly use these entitlements.

You can read more about much of these settings (which again I think is an overly complicated way to handle a problem) in these articles:

• Convert Driver Entitlements to New RBPM 3.7 Resource Model

• Converting Entitlements to Resources, more details

That about covers the configuration of the driver. This is a full bidirectional driver with a full Publisher and Subscriber channel, so since I usually like to start with the Subscriber channel, I think I will start there this time as well.

Subscriber Channel:

The Event Transform polict set is empty, and thus we move on to the Match policy set.

Matching:

There are three policy objects here,

• NOVLEDIR2DCF-sub-mp-Scoping

• NOVLEDIR2ENT-sub-mp-EntitlementsImpl

• NOVLEDIR2DCF-sub-mp

What is nice is that there is now some consistency across the drivers that Novell packaged for IDM 4 and if you have read any of my other recent walk through articles, these should look familiar. First the scoping policy will check for out of scope objects and use an operation property to carry it through, then if it is allowed, the entitlement policy will be enforced (require one or not) and then the actual match will be tried if we are in scope.

NOVLEDIR2DCF-sub-mp-Scoping

Here we have a single rule, called remember relative position in hierarchy. This is used so we can use the Unmatched Source DN noun token, which only works right after a If Source DN in subtree style test. In order to use this inforamtion later (for mirrored placement for example) we need to store it, so it gets written to an operation property, 'unmatched-src-dn' which usually confuses people, since they assume that is what the token is reading or else writing, when in fact it is just a manual step taken in many driver configurations.

Also, if the event is in scope, then the 'attempt-to-match' op property is set to true. This will be used later to veto out of scope events.

NOVLEDIR2ENT-sub-mp-EntitlementsImpl

This has a simple single rule, Veto if User not entitled to an account. If the GCV for requiring entitlements is enabled and there is no entitlement veto the event.

NOVLEDIR2DCF-sub-mp

Here we have three matching rules.

• match Users by UID

• match Users by CN

• match everything else

• match Users by UID

• match Users by CN

These two rules take the same approach. If the drv.subplacement GCV is set to flat, then search by Given Name and Surname, as a subtree search, starting at the base container. This seems wrong to me and I will report it.

Then if the GCV is not flat (imply mirrored) it substrings out the first 3 characters to get rid of the cn= part, then adds back in the cn= then the Op Property unmatched-src-dn recently set, followed by the base container to build a mirrored DN placement.

• match everything else

Finally this rule tries to match other objects, which would include Organizational Unit ibjects and whatever else you let through your filter. The condition is for all objects NOT equal to User, and then if the placement GCV is set to flat, then they use the Source DN token, and its built in ParseDN functionality to start at -1 and go for a length of 1, which means take the leaf most node (i.e. the object name) and then append a comma and the connected systems base DN.

If placement is not flat, then the unmatched-src-dn is used followed by a comma and then the base container.

This is pretty much how most of the base drivers are configured these days in Packages and is nice since it maitains consistency between them for administrators.

Creation:

There are three policy objects here, and one of them is a new one, the NOVLEDIR2PSY package, the Password Sync package.

• NOVLEDIR2PSY-sub-cp-PasswordCheck

• NOVLEDIR2ENT-sub-cp-EntitlementsImpl

• NOVLEDIR2DFC-sub-cp

NOVLEDIR2PSY-sub-cp-PasswordCheck

There is one rule here:
Check whether the password is available

This is interesting in how it uses Condition groups. There are 5 condition groups, AND'ed together. So the operatrion will be vetoed if it is an <add> which is not needed in a Create Policy since it can only ever be an add here.

Then it needs to be a User.

Then if either the operation attribute nspmDistributionPassword (Used for Password Sync 2.0) is not available, or else is equal to blank.

Then if the attribute Private Key is not available or is blank. This and Public Key which is used in the next condition make up the NDS password, used in Password Sync 1.0,

Finally if the Public Key in not available or blank.

If all five conditions are true, then we have a password missing and we veto. If there had been a password, then one of Public Key, Private Key, and nspmDistributionPassword would be available.

What is interesting with this is that in the filter, the nspmDistributionPassword is set to sync in both directions and the Private Key/Public Key pairing is set to ignore in both directions.

I do not think you can have conlditional logic in Filter Extensions (Which I would love, if possible, but I am not aware of it) so I wonder what the thinking here is.

NOVLEDIR2ENT-sub-cp-EntitlementsImpl

In the Match policy we checked for the Entitlement, and if the GCV enabling entitlements is on, then we stopped matching if the entitlement was missing. Of course, they should have just vetoed then, but instead in this policy there are two rules:

Account Entitlement: Veto account creation when entitlement not granted

This vetoes the add event if the entitlement is not there, and entitlement processing is enabled by GCV.

Signal the need to check group entitilements after the add

If there is a group entitlement we want to wait for the <add-association> event to know we succeded in adding the user, and to then go check for any group entitlements and add them. After all, adding a non-existing object to a group is going to fail, better to wait for completion. So to indicate this, an op property is set, check-group-entitlements to true. We will see in the Input Transform that this is used at that time.

NOVLEDIR2DFC-sub-cp

There are three rules in my Packaged version, but the last two are disabled. The disabled ones are password checks, and Organizational Unit requirements. For Users, it is just requiring a Surname, which is somewhat silly, since coming out of eDirectory, you must have a Surname to exist in the first place. I am working with somewhat early copies of packages, so this will likely be cleaned up by release time.

The disabled veto if no password attribute makes me think they will rely on the Default Password rule in the Sub Command set. However there is a previous check in the Sub Create policies that vetos this earlier if no password available.

NOVELDIR2DFC-sub-pp

There is only one policy object and one placement rule in the Placement Policy set.

This rule checks if the object is in the subtree defined in the GCV idv.dit.data.users

Then it checks the drv.subPlacementType GCV to see if the value is flat, in which case the destination DN is the cn=Username a comma, and then the placement GCV value (drv.edir.base.container).

If the value of drv.subPlacementType is not flat (mirrored in other words) then they use the Unmatched Src Dn() token to get the remaining DN of the user after you subtract the part that was in the IF Source DN in subtree test.

I.e. For a user cn=geoffc, ou=Testing, ou=Users, ou=Something, o=acme, dc=com and your idv.dit.data.users GCV says ou=Something, o=acme, dc=com, then the Unmatched Source DN value is what remains once you subtract that part from the full DN. I.e. cn=geoffc, ou=Testing, ou=Users so this way you can mirror placement very easily.

Other drivers may confuse, since the new Novell package approach is to have a scoping rule that does the test and stores the Unmatched Source DN value in an operation property so you almost might think that the way the token works is to write that op prop for you. But it does not.

Anyway, that about wraps up this article. Stay tuned for the rest of the series.