Micro Focus Identity Manager is a pretty complex product. The engine happens to be my favorite part. It is designed to synchronize data between disparate systems, and as the years have progressed has gotten pretty complex and interesting.

At the core is the Identity Manager engine (vrdim.dlm and dxevent.dlm on Windows, dxevent and vrdim in "ndstrace -c modules"). There is a module dxevent that plugs into eDirectory to capture events as they happen in the directory. Then there is the engine itself that processes everything in Java via vrdim. Originally the product was going to be called Virtual Replicas, thus the VR part. For general interest, vrdim loads the jvmload module, which starts the JVM for IDM inside the eDirectory memory space. (Often when IDM kills eDirectory these two modules are involved).

This allowed the engine to collect events as they occur in the directory (regardless of who generated the event) to send. (This is what is sent into the Subscriber channel).

This was initially meant to synchronize data from eDirectory (the Identity Vault) to the connected applications.

On the other end, there is a driver shim that knows how to talk to the connected systems. Some of them are vendor specific like the Lotus (Domino) Notes driver that is a Notes program that can manage Notes databases. There is an Active Directory driver that knows how to talk to Active Directory and pick up events from that system. These are the events that get sent into the Publisher channel.

A fun twist was added with the concept of Entitlements, where an object could be used to represent all the Groups in another system, and simply referencing the Entitlement object (which some definition of what the objects are) and a value to specify the proper target, you can manage groups in that remote system.

This was meant to happen automatically and not require any user intervention. The system would run. Someone in HR would hire/fire/modify a user and the data would flow, the consequences would consequent.

Later, they added the ability to design workflows, where users can intervene in some of these actions, and request additional access or approve/deny some of the changes.

Some of this required Roles and then Resources. Alas, Resources feel a little like a step backwards, as an Entitlement for Groups in Active Directory is a single object, and if you reference it properly (via the DirXML-EntitlementRef attribute added to a user with a value that describes the group) it is just the value you pass it that adds the user to the group. I.e One object, but unlimited values. (If you have 100,000 groups one object still, just 100,000 possible values to pass it).

Resources sort of statically unroll that simplicity and now you require a Resource object for each possible value. Some of this was designed to allow human readable names to be assigned to different groups. (The values were typically GUID's which are not human readable/usable). I lament this decision, but it is what it is and we move on.

Initially there was no way to automate making a Resource for every possible value, which means you need to make them by hand, or script it or something. With IDM 4.5 or so they added in support for something they called PCRS - Permission Collection and Reconciliation Service. This actually had two main bits of functionality. First create a Resource for every 'permission' (be that a group, role, or widget in the target system, so long as you have it defined as an entitlement). Second it would try to determine if anyone in the target system, has the permission and then assign the newly created resource to the proper users in the Identity Vault. Thus it would collect permissions (create the Resources needed) and reconcile them (manage the Resource assignments).

This was a good idea, but probably more complex than necessary. It was initially done all in policy, and I once tried unrolling and discussing the policies, but it was so complex I eventually gave up.

But all this generates a lot of functionality in a product that gets more complex over time.

At its core though is the IDM engine. The issue of the various channels on the engine is often confusing to folk, so I thought it worth discussing.

Simply put (as explained above), events coming out of the engine, heading to the application flows along the Subscriber channel. Events coming out of the application, headed towards the Identity Vault flow along the Publisher channel.

This is represented in iManager, as right or leftwards. Being a smidgen right-left dyslexic I found this hard to remember. The metaphor is that of the Identity Vault as the 'backbone' of the view, the hub, with drivers coming off it as spokes on both sides. Designer has a bit more free space to play around in, but has the same basic metaphor.

When showing a driver flow, it always shows the Identity Vault on the left, and the driver comes off it to the right. Thus the Subscriber channel (Events coming out of the engine, headed towards the application) is pointed to the right, towards the icon for the application. Conversely the Publisher channel is pointed the other way, leftwards, starting at the application and headed towards the Identity Vault.

In Designer the view of the flow is up and down, which I personally find much easier to remember. It is interesting how silly the difference between side to side vs up and down can make. Brains are strange things.

The Identity Vault is at the bottom of the view in Designer in the policy flow view, and the Subscriber channel has events flowing up towards the application. The Publisher channel starts at the application, and flows down towards the Identity Vault.

On the Publisher channel, events in the application are sent to eDirectory. Each driver implements detecting changes to send differently, and in general, there are three basic families of approaches. Of course there are more I am sure, feel free to drop a comment if you know of any I missed.

1. Some native API for detecting changed events. Active Directory uses the Dir Sync cookie. Some SOAP endpoints let you query for changes between Date1 and Date2. In fact SOAP endpoints often have the wackiest query options.
   

• Triggers in the application, like in databases. In fact, triggers are sort of a database concept. This is great, since you get real time eventing.
  

• Triggerless (the JDBC driver can do this). In this case pull back all data, compare to the version stored in a State DB (Stored in DIB dir in MapDB/jdbm format). Watch out when you upgrade, this jdbm/MapDB library changed between IDM versions. You can do this in all sorts of application shims, not just database shims.
  

For the Subscriber channel, the dxevent module, which watches for events that are registered (by the filter, so by object class and then attribute) collects the events and caches in a .TAO file in the dib directory. You can view this in iManager when the driver is stopped (Driver cache inspector). You can find the TAO file by looking at the driver in iMonitor to gets its ObjectID, which is in hexadecimal, convert that to decimal, and in the dib directory (On Linux, this by default is usually /var/opt/novell/eDirectory/data/dib) look for *.TAO and find the proper object ID in the file name. The default empty size is 72 bytes. You can watch it grow and shrink as events come in, get processed, and get removed.

You can look at the contents of the cache, but the driver has to be stopped, alas. It would be so super cool to look at the events live, and maybe kill the event that is stuck at the top of the queue live without stopping the driver. But alas, you cannot. You can export the contents as XML to a text file, via 'dxcmd' (find your driver, cache operations) and you can even replay them later via dxcmd as well.

With IDM 4.5 and higher they added a new feature called Out of Band sync, where there is a second cache file, so you can flag an attribute so that it syncs out of band from the main cache. That means you can flag, say the password attribute (the obvious choice) so that it jumps the queue and processes as soon as the current event is finished. This way it does not get stuck behind HR dumping in a reorganization event. Previously for large environments I had implemented a second driver instance to the same system, dedicated to just password sync to mimic this event. Now it is built in.

With IDM 4.6 and 4.7 there is a new channel added, but alas, we have no access to it yet, that can be used by the Code Map Refresh process, to handle the queries that need to be done to retrieve entitlements, so as to stop blocking regular events, and also to allow the query to run better. I have yet to see how we can utilize this channel. I am waiting to see if there is some way to leverage it. It would be fun to have our own channel for events if possible. The shim needs to be updated to support it, and is currently just Active Directory, Azure Active Directory, Multi-Domain Active Directory, and the JDBC drivers that support it.

The Filter control the information that is placed into the channel. There are 4 settings, per channel.

None - an event in the channel source (Sub source = Vault, Pub source = application).
Sync - an event in the channel source is sent to the destination.
Notify - The event in the channel source is started into the channel. It is then stripped out by name, after completing the Command Transform.
Reset - If the attribute in the source changes, then undo the change and set it back to the previous value.

The comment that spurred me to write this was about the eDir to eDir driver, which is actually the most complex and confusing driver of them all, perhaps it is better to address it directly.

Up till now I have been focusing on every other driver except eDir to eDir, (it is true for eDir driver, just more complicated).

So for the eDir to eDir driver you need to realize that there are 2 drivers involved. One in each tree. Each consists of a full IDM engine. Thus there are two complete, and independent drivers. That means two complete and independent (but related) filters (and policies), which makes troubleshooting it pretty hard.

Functionally I have found the best way to think about it, is that all work is done inbound to the vault.

To think about the eDir drivers, think about doing filtering outbound events on each side in the Sub-Event. So block deletes, renames, moves or not there. But that is about all you should do in that channel of that half of the driver. On a side note, be werry werry careful of those wascally wabbits, and when you add a Veto in the Sub Event of a driver, you need to make sure to include an event type (If Operation equals add) or a class (if class name equal User) otherwise you could veto the &ltr;init-params&gtr; startup event and then the driver fails to start up. I of course did this almost 10 years ago, and was stumped till a friend figured it out. (Side side note: If you get stuck, a fresh set of eyes usually can see it right away).

Then basically do everything else inbound on the other driver in the Pub channel. This makes troubleshooting much easier. Either your event occurred outbound, was or was not filtered in the Subscriber Event Transform. If it gets out of this half of the shim, every other problem is thus in the other side. So you can quickly eliminate the issue as being on this side, and move on to narrow it down to the inbound side.

Otherwise troubleshooting this kind of driver can be hell. Watch out for queries, they are confusing since they need to flow back and forth and seem to get in the way, interleave, and make you wonder, why did my event suddenly stop. If you follow it further you will see that the response will eventually be processed, but it can be very confusing.