IGI Internal Events

IGI gurus should understand that adding rules to Live Events is really the only way you are going to get maximum value from your IGI deployment. Out of the box features within identity tools are rarely sufficiently detailed enough to allow for production deployment and there is always a need to enhance these processes with organisation-specific rules and definitions.

IGI gurus will also be aware that the firing of rules can be somewhat hit and miss. Placing objects into the USER_ERC table will fire a Live Event on the IN queue, but writing an advanced rule to perform a SQL update of the same database table using the internal scheduler will NOT fire a Live Event!

Similarly, modifying a user in the Administration Console will not fire an event either unless you specifically "Enable Internal Events" on your Settings tab.

Enabling Internal Events, however, will only allow a handful of events to trigger a rule, For example, you can add business logic to the Add Entitlement event, but you cannot add business logic to the Publish Entitlement event or the Add Entitlement to an OU event. Maybe one day this will be enabled (and I really hope some of the IBM Development Team read this)!

Anyone who has ever enabled internal events, then clicked on the Monitor/INTERNAL tab to view the events may be sorely disappointed. I call it the "Tab of Disappointment" and why? Well, it will be empty. No matter what events are being fired, it will be empty. That is, until you add this little gem to your system:

when
    event : EventBean(  )
then
/*
 *  Version: 1.0
 *  Date   : 2018-02-28
 *  Purpose: Saves the event so it is viewable in the logs
 */
    event.setState(1l);

This piece of code should be added to the BEFORE ruleflow within Rules/Live/Internal. This code instructs the platform to always save the event within the database tables which makes the event visible in the Monitor/INTERNAL tab.

Now you can see what is going on in your system and maybe even replay events.

NOTE: Should you wish to look in your log files for anything you may be spewing out from your rules within Rules/Live/Internal, you may have to look at the accessgovernancecore_event_out.log file. Don't ask why!

Déjà Vu - IGI Handling of AD Dormant Accounts

I know I had this problem years ago with ISIM. Why do I have this problem again with IGI?

Years ago, the ISIM adapter for Active Directory would reconcile the Last Logon Date that was specific to which ever Domain Controller the adapter connected to. That meant, of course, that the REAL last logon date for a user was not being reconciled and any life-cycle rule built to query that attribute and act upon the value contained therein would, in all probability, cause a major "hoo-ha".

IBM resolved the issue by adding erADLastLogonTimeStamp which returned the domain replicated last logon date (albeit, the date could be +/- 14 days in accuracy for reasons which Bill Gates would be best to explain).

IGI is a new product but uses the ISIM adapters. However, the internal IGI mapping for of Last Logon is using the old erADLastLogon date rather than the slightly more reliable erADLastLogonTimeStamp.

Doh!

What are these crazy kids thinking? Did the ISIM guys not talk to the IGI guys? (That said, I've checked the latest resource.def file for the ISIM adapter and I'm disappointed to report that the erLastAccessDate mapping is set to erADLastLogon!).

In any case... if you want to run any kind of dormancy rule on Active Directory accounts in IGI, make sure you do this BEFORE you reconcile your service:

update itimuser.entity_schema_mapping set custom_attribute_name='eradlastlogontimestamp' where custom_class_name='eradaccount' and system_attribute_name='erlastaccessdate';

This little gem will ensure that the correct AD attribute is used as the last access date rather than the pitiful erADLastLogon attribute which is borderline useless.

Maybe IBM will update their configuration and resource.def file and documentation at some point (again).