Introducing... Madigan Solutions

This blog hasn't seen much action over the last year or so. That's not because I haven't got things to say, but I was definitely lacking in time to do so.

In any case - I've been busying myself with a new venture and most of the tooling and content of my personal website will disappear in the coming days.

Instead, I would encourage avid readers (and there may be one or two of those) to pop along to https://www.madigansolutions.com/.

This blog can now be considered "functionally complete" and probably irrelevant given the dates on many of the articles.

It's been a blast and it will continue to be a blast with the rest of the Madigan folk.

IGI & NFS Mounts

The IBM knowledge base reads like it was constructed by a technical writer who has very little experience of actually using the products they are describing. At least, that is how I read most of the official documentation.

Frequently, documentation might tell you how to do something, but it won't necessarily tell you why you should do it; what circumstances would require you to do it; and even the steps described are often missing some key piece of information.

The documentation that supports how to create an NFS Mount Point for Enterprise Connector input files is a case in point:

• the documentation describes what you need to do, ish
• the documentation is lacking why you need to do it
• the documentation only provides one side of the NFS equation

Why would you move your files to an NFS Mount Point?

If you have an IGI cluster (and if you are running a Production Service, you really ought to have a cluster), then you MUST use NFS for your input files! You need all of your cluster members to be accessing the same source repository for your files and the ONLY way to do that is via NFS.

What do you need to do at the NFS Server side?

Well, let's take a Red Hat based system as an example for hosting our input files. You would perform the following tasks:

yum -y install nfs-utils

useradd -u 50001 identity

mkdir /nfsroot

mkdir /nfsroot/connectors

chown -R identity:identity /nfsroot/connectors

echo "/nfsroot 10.10.10.0/24(rw,no_subtree_check)" > /etc/exports

systemctl start nfs

systemctl enable nfs

NOTE: Change 10.10.10.0 to your subnet as appropriate.

NOTE: Update your firewall rules to allow traffic on ports 111 (TCP/UDP) and 2049 (TCP).

What do you need to do at the IGI Appliance side?

Navigate to Manage > Network Settings > Network File System, then click on the New icon.

Complete the following:

• Host Name: Linux Server Name or IP Address which hosts your NFS service
• Remote Directory: /nfsroot
• Local Directory: linuxserver

NOTE: Change linuxserver to whatever label you desire.

What do you need to do at the IGI Application side?

Navigate to Enterprise Connectors and create your CSV based connector as normal but within the Input Folder attribute, use the following syntax:

/nfsmount/linuxserver/application

NOTE: Change linuxserver to whatever you set within the Appliance.
NOTE: Ensure that the application folder exists on the Linux Server for the relevant application you are creating a connector for. (Ideally, this would mirror your application name, right?)

And that, my friends, is that!

IAM Respite - Champagne Time

I say Champagne Time. I don't really mean that. I mean there's a bottle of Champagne up for grabs as part of my Guinness Six Nations 2019 predictor game.

It's a simple game. 15 matches. 15 score predictions. The most accurate person walks off with Champagne (or a substitute drink of their choice).

It's free to enter; takes only marginal skill; and enhances the joy of the tournament.

Don't be shy - give it a go and forget all about that Identity & Access Management stuff for a few minutes.

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).

IGI Default Account Attributes

DISCLAIMER: This article is not applicable to IGI v5.2.3 or later!

Setting account defaults in IGI is rather like setting account defaults in IBM Security Identity Manager (ISIM). For those familiar with both products, you will recognise that the ISIM screens were copied/pasted into the IGI platform with very little alteration. (One difference, of course, is the ability to set enforcement on attributes, but dealing with that is one for another day!)

Provisioning a new account can be tricky to troubleshoot, however. It seems that the logging levels can be less than helpful in certain circumstances. Consider the dreaded java.lang.NullPointerException! This can be thrown by the provisioning engine when the account defaults code is problematic.

Consider that we have a need to set an attribute in a provisioning target to the value of ATTR2 on our identity record, but only when ATTR1 is set to Y. You might consider using the following code:

if (subject.getPropertyAsString("attr1") == "Y") {
  return subject.getPropertyAsString("attr2");
}

The code looks great, but this code will throw our dreaded NPE in certain circumstances. Not only that, but our logs won't actually tell us which attribute and therefore which section of code is causing our NPE. Why does this happen?

Well, the provisioning engine MUST get an object returned from our code in ALL circumstances and the above code only returns a value if ATTR1 is set to Y. To avoid our NPE, we need to complete the code as such:

if (subject.getPropertyAsString("attr1") == "Y") {
  return subject.getPropertyAsString("attr2");
} else {
  return "";
}

The addition of a return statement within the ELSE clause will ensure we always return something. Our NullPointerException won't appear again...

IGI - Careful With Those Hierarchies

One of the beauties of IBM Security Identity Governance & Intelligence (IGI) is the ability to create custom "hierarchies" which I've discussed elsewhere in this blog. So much power, yet so much frustration too. These things need a LOT of tender love and care.

How so? Well, for two reasons:

• Batch only rebuilds rather than "on-the-fly" insertions; and
• Non-completion of a rebuild

Batch Only Rebuilds
Hierarchies are rebuilt by a batch process handled within the Task Planner. This rebuild iterates over every PERSON object in the data repository and re-evaluates the hierarchy location for each and every user which is fine for re-synchronisation of a hierarchy against the PERSON objects.

But if a new PERSON appears in the system, they won't inherit their birthright entitlements until the hierarchy is regenerated. If there are a large number of PERSON objects in the system, a hierarchy rebuild may take some considerable time and may be scheduled to only execute once a day! Hardly ideal.

Fortunately, the upcoming latest and greatest version of IGI is supposed to address this inadequacy and should support "on-the-fly" insertion of PERSON objects into any hierarchy (and not just the Organisational Unit Hierarchy).

Non-Completion of Rebuilds

The lack of "on-the-fly" insertions of PERSON objects into a hierarchy is doubly troublesome because a hierarchy rebuild may fail! Remember, a rebuild iterates over every PERSON object in the underlying repository. A failure to process any one of those PERSON objects could result in the hierarchy rebuild stopping.

In other words, in a system of 20,000 people, a failure to process person number 19,999 will mean that person number 20,000 will not get processed at all! To put that another way, the system does not FLAG the failure to process a person and basically abandons processing all subsequent users.

Oh dear! So what can cause a failure and should our custom hierarchy construction code be more robust? Unfortunately, our custom hierarchy construction code probably has nothing to do with any failure as there are a myriad of other reasons why a hierarchy build would merely stop (after a bout of hissy-fitting). Take these two examples:

• Insertion of a user into a hierarchy triggers the creation of an account as a result of a birthright entitlements attached to the hierarchy node; but the account creation throws an error because it attempts to re-use the Master UID of the user to create the account but an account with that ID already exists!
• Insertion of a user into a hierarchy triggers the addition of an entitlement to a user's account as a result of a birthright entitlement attached to the hierarchy node; but the user seems to already own two accounts for that service - something which should not be possible with IGI in the current version (v5.2.2) but seemingly IS possible under certain circumstances!

In other words, it doesn't matter how robust your hierarchy construction code is, the quality of the underlying data could throw quite a major spanner into the works! Of course, a better approach would be for the core IGI engine to handle such issues and at least move on to the next PERSON object to be processed. Maybe in the next release!

Meantime... take care of that data! Get a handle on your orphan management processes and check for duplicates. The following  SQL command will help you with that particular diagnosis:

select pw.pwdcfg,pw.person,p.code,count(*)

from pwdmanagement pw

left join person p on pw.person=p.id

where pw.person is not null

group by pw.pwdcfg,pw.person,p.code

having count(*)>1;