The release of IDM 4 SP2 includes 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 the second article I discussed the GCV's (Global Configuration Variables) that come with the driver, and then on to policy walkthroughs, making it as far as the end of the Subscriber Placement policy.

In the third article I started in on the Subscriber Command Transform policy set.

In the fourth article I finished the Subscriber Command Transform, and Output Trasnsform and just started into the Input Transform.

In this article I will continue through the Input Transform.

Input Transform:

The Input Transform has seven policy objects from five packages.

• NOVLEDIR2ENT-itp-InitEntitlementsConfigurationResource

• NOVLAUDTENTC-itp-SendEntitlementEvents

• NOVLEDIR2MSI-itp-InitManagedSystemInfo

• NOVLATRKBASE-itp-Publish

• NOVLATRKBASE-itp-WriteAccounts

• NOVLPWDSYNC-itp-EmailOnFailedPwdSync

• NOVLEDIR2ENT-itp-EntitlementsImpl

I finished the first policy in the previous article, now onwards to the next!

NOVLAUDTENTC-itp-SendEntitlementEvents

When using Entitlements you probably want to notify some kind of audit system that they have been granted. Now you can do this from several ends. You can have the agent that grants the entitlement be it workflow, the Roles Based Entitlements driver, or something else send an audit event. You still need to complete the loop and keep the auditors happy, since those are just technically just the grant of the entitlement. You also want an audit event when you actually use or implement the entitlement. You can imagine a broken driver where an entitlement is granted (audit event sent) and then not actually implemented due to a broken driver. (I am not sure how much I really care, but it is a reasonable request).

This policy has 5 rules, 4 to handle the various kinds of events we set in the Output transform as operation data:

• accountCreatedByEntitiementGrant

• accounteDeletedByEntitlementRevoke

• accountDisabledByEntitlementRevoke

• accountEnabledByEntitlementGrant

Each gets its own Audit event number set into a variable and not much of interest otherwise.

The last rule uses the variables set, and build the Generate Audit token, which takes the values:

id= the value set earlier for each of the 4 cases.
level = log-info
value3 = version (which is set to 1 in this rule earlier).
targetType = 4, which is a comment on DN formatting as I recall.
subTarget = accountAction (one of the above 4 actions), an underscore, and then the audit event id, an underscore, and then the Status events level, (warning, error, success, etc).
status = uses a cute replace all, to code in 0 for success, 1 for retry, 2 for warning, 3 for error, and 4 for fatal.
text3 = the XML attribute event-id of the status document.
text1 = GUID of the object, carried by an operation property guid
data = IDM eventID "the event ID" level: 'the level XML attr'
text2 = Object Class: "the object class"

NOVLEDIR2MSI-itp-InitManagedSystemInfo

This is another of those run on every driver startup rules that I am not a huge fan of. This one at least checks to see if the calculated values match the current values and only write them if different, which seems like it is different from the original version of the Entitlements Configuration version I had checked, but now also only writes if the calculated values are different.

Regardless, this is one of those I do not see why they could not just prompt for the info needed and let the admin enter it. Why do we need the driver to update itself? And if it can be expressed in policy then unless there is some dynamic component that needs to change why not just configure it once and leave it alone.

You can read more about how the MSysInfo object, which is DirXML-GlobalConfig object holding GCV values is used by the Managed System Gateway, and Data Collection Gateway drivers in these articles:

• Data Collection Service Series

• Managed System Gateway Series

There is truly a ton of stuff going on here, and it is outside the scope of this article series to discuss it. The only part that is of interest is that the msysinfo.drv.ms.type attribute gets a value hardcoded from this rule, and usually it is 2 upper case characters, but for this driver the value is EDIR. With the initial release of IDM 4 and even IDM 4.01 I noticed a number of the drivers were based on the Active Directory package and left the value AD in this rule. Since there are no clear guidlines on how long this field should be, it is good to infer from this that 4 characters are allowed.

• NOVLATRKBASE-itp-Publish

• NOVLATRKBASE-itp-WriteAccounts

I discussed these two policies before, and I will carve that out into an article series on its own, but again these are actually much more complicated that they need to be (to my mind, but remember it is easy to criticize, it is harder to do) and their basic purpose is to look at the event and decide if this was an enable or disable event.

Basically Account Trackings goal is to maintain the attribute DirXML-Accounts which the Sentinel driver basically sends unaltered (there is almost no policy in those drivers) as part of Identity Tracking in Sentinel. That is the attribute Sentinel uses to decide if the account is active (and present) or not. The work to decide is left to each driver, which uses these policies to manage the DirXML-Accounts value.

NOVLPWDSYNC-itp-EmailOnFailedPwdSync

This rule is discussed in my series on the Password Sync policies, and basically it is used to send emails on password synchronization failures, if the controlling GCV's (Set in Designer's Password Management panel, or iManager's Server Variables tab) enable it.

You can read more of that series here:

• Password Transformation Rule Sets

• Password Transformation Rules in the Publisher Channel

NOVLEDIR2ENT-itp-EntitlementsImpl

This is a pretty typical Entitlements implementation rule. It does two separate things in two rules.

Intercept eDirAccount (tagged identity query) query response

This rule, looks for a tagged query, which we saw modified in the Output Transform, in the policy object NOVLEDIR2ENT-otp-EntitlementsImpl where certain events (which I think come from Reporting) get reformated to the kind that returns basic driver information and always succeed. Then when that specific response comes back it reformats the response <instance> document to basically a static response. I.e. It never changes, which really makes me wonder why they bother? I think there is at least one driver (my guess is SAP UM) which can actually have real response values, and none of the other drivers implemented the same code, therefore this policy is needed to sanitize the non-supporting drivers.

It pretty much comes out looking like this, when done:

<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product version="?.?.?.?">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <instance class-name="eDirAccount" src-dn="eDirectory Server">
      <attr attr-name="eDirAccountDisplayName">
        <value>eDirectory Server</value>
      </attr>
      <attr attr-name="eDirAccountDescription">
        <value>eDirectory Server</value>
      </attr>
      <attr attr-name="eDirAccountValue">
        <value>eDirectory Server</value>
      </attr>
    </instance>
  </input>
</nds>

Google Apps does the same thing with Google substituted for eDir.

Check target of add-association for group membership entitlements that need to be granted

The second rule is meant to handle Group Entitlements. The usual chicken and egg issue comes up here where it is awkward and possibly a race condition to add a user to a group when the user may not yet exist. To resolve those cases, what happens is when a User is created, which you can tell by the add-association event type, and secondarily an operation property set earlier in the Subscriber Command to indicate this was a user creation event. After all other objects, like Groups can be synced and an add-association event for them ought not to fire. Though based on how the rule works it would not actually hurt. This is because it loops over any Entitlements on the object, of name Group. Well Group or other objects would not have that entitlement so it would just loop zero times in those cases.

Inside the loop, for each Entitlement Group found, it uses the ECMA function es:getEntParamField to get the ID field out of the entitlement payload. (Recall from earlier that the formats of this field changed between IDM 3.6 (simple string) to 3.6.1 (pipe separated string for multiple values) and 4.0 (JSON, key value pairs))

Then it adds uniqueMember attributes to the Group object with this user, (since we are in the ITP before the schema map, we use remote schema names, and since this driver is a modified copy of the LDAP driver, this is probably a left over bug in my early copy of the package, since eDirectory usually does not use uniqueMember attributes. Now it is possible that a default LDAP server mapping in eDirectory is uniqueMember to Member but I do not recall if that is the case or not) and finally adds an XML attribute, association-ref, using the current association value (Retrieved from the <add-association> event with a somewhat odd looking XPATH, but one that works of ./text() since the <add-association> event looks a little different than usual XDS events, and the only text node in the document is the association value) to the modify node.

This is because objects in connected systems when they are DN style references, the engine expects an association value to unqiuely find the object. During creation that clearly won't work since nothing exists, so at that time we use the Destination DN, to specify where it should be created, but after that we generally use association values.

That about wraps up the Input Transform policy set. Onwards to the Publsher channel.

First up of course is the Event Transform policy set which has a single policy object.

NOVLEDIR2ENT-pub-etp-EntitlementsImpl

There are two rules in this policy object.

Disallow user account delete when using entitlements

This rule considers what happens, if entitlements are in use, and the user in the connected eDirectory is deleted. Do we let the event flow through? Well not when entitlements are in use. But we do clean up in the Identity Vault by removing the association, and blocking the delete event. They do the remove association action, after the current event so that the following veto does not affect it and instead vetos the delete, not the following remove association.

Strip Login Disabled from operation (Disable Option)

As discussed before the User Account entitlement when removed, can cause a delete or a disable in the connected system depending on how a GCV is set.

Well if we are using Disable, then it is the entitlement that owns the Login Disabled attribute, which would otherwise synchronize freely in both directions. Thus in that case, we would remove the Login Disabled attribute from the operation. This does leave us out of sync, but keeps the Entitlement in control. I wonder if it would make more sense to reset the Login Disabled at the same time as well?

I also wonder if this will handle a merge case properly? In a merge, the modify (now stripped of Login Disabled) will be converted to a synthetic add, which we add the login disbaled back into the event document since it is in the filter, and then if a matching object is found, will consider the data in both systems, apply the merge authority rules and update both sides as appropriate. Looking ahead I see no rule in the Command Transform to handle this case, so it makes me wonder.

Regardless this rule triggers when the use of entitlements is enabled by GCV, and the Remove action is set to disable, for a User object and Login Disabled is in the event document with a value being added.

That about wraps up the Publisher Event transformation policy set, and there are just a few more rules to go in this driver, with three of the common approach rules in the Match policy set, one placement rule, and really just one Command Transform rule, which is designed to handle the Distribution Password fun, (and private key/public key pair syncing) since this driver is already talking to eDirectory at both ends. (There is no create rule, since the default requirements to create a user in eDirectory must have been met already to create a user in the source eDirectory. Of course you would have to add your own custom requirements should they exist.). Stay tuned for the next exciting episode in this series.

If you have been finding these articles useful, please consider looking at a driver you are familiar with and contributing a similar style article. There are so many drivers, and so little spare time for me to write about them, I would love to see others writing these sorts of articles as well. I have been collecting these style write ups on a Wiki page, which you can see here: http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection

If you want something added to that page, it is a Wiki, so you can edit it in yourself.