NetIQ IDM Drivers and Out-Of-Band Sync

When working with NetIQ IDM drivers it is well understood that the typical driver events are processed in a “first-in-first-out” order meaning that the first transaction detected by the driver is the first transaction processed and any subsequent transactions are queued by the driver which are then processed in the order they appeared.  Very much like people lining up in a line to checkout at a retail store.  The person in the front of the line of checked out, then the person behind them, and so on and so on.

However, what if there is certain data that you want to give priority to so that it jumps to the front of the line?  If the drivers process data in a first-in-first-out manner can priority be given to such data?

Yes, you can, but it comes with a warning.

Simply put, if you look at the driver’s filter and more specifically at the attribute(s) in the filter that you want to give priority to, you will find an option that says “Perform Out of Band Sync (Subscriber)” with two options; “Yes” and “No” with “No” being the default value.


If you change that setting to “Yes” for the desired attribute(s) then any changes to those values will be given priority and moved to the front of any queue that may be built up for that driver.  Now, it should be pointed out that if multiple changes are made to attributes that are given priority then a queue of those high priority events will build at the top of the driver queue with the high priority values being processed in a similar first-in-first-out fashion before any normal priority events are processed.

Now, the warning that comes with this setting is this; if a priority attribute is changed on an object that does not have a valid association for that driver it will not synchronize properly.

When the values are given the high-priority status the transactions that include them skip the normal processing order.  It will skip any matching rules in the drivers that would normally be used to find an existing object in the destination.  This means the driver assumes that the high priority attributes belong to an already known target and attempt to perform a direct sync.  For known, associated objects this is perfect and no issues occur, however, for unassociated objects, the driver does not know what target needs to receive the update in the connected system.  This results in an error in the driver log along the lines of “veto on unassociated object”. (see sample transaction below)

For many IDM systems, this is not an issue that would be encountered often, especially for accounts/objects provisioned through/by IDM.  Where one might expect to run into this is when implementing IDM into an existing environment without fully migrating existing accounts or extending an existing IDM environment to include new systems without fully migrating existing accounts.

The moral of this story: if you want to give priority sync access to one or more attributes in a driver, make sure all of your accounts are associated for that driver or be prepared for the priority changes to not sync properly.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *