Dynamic Organizational Unit provisioning with ILM 2007/MIIS 2003

System administrators are often facing task of creating OU structure in a corporate LDAP directory(es), such as Active Directory, ADAM/ADLDS, OpenLDAP, eDirectory etc. In the organization where administrator is asked to place user account object in the OU corresponding to user’s department, title or any other dynamically calculated container based on the user’s attributes, (s)he must know (and therefore hardcode) values of target containers/organizational units in the LDAP connected directory in question.

MIIS 2003/ILM 2007 developer reference is rich with examples of placing user account within pre-defined OU based on the OU’s name. In the event when parent OU if not available administrator is expected to create an organizational unit object manually. In the same time, should organization extend list of the departments (and therefore list of the corresponding OUs), the provisioning code will have to be augmented to include new values (path) and provisioning/de-provisioning business logic for newly added target OUs.

To avoid this practice of re-compiling of provisioning code for every adjustment in the organizational structure of an enterprise administrator could implement a mechanism to create parent organizational units dynamically, based on the attribute values of the user object in the Metaverse.

This code example also provides clear path for de-provisioning of the user account in the future. To illustrate challenge of dynamic provisioning of OUs based on the "user" object-type provisioning cycle, we will need to understand the initial provisioning logic of the first user account that encountered the condition where parent OU was missing. Code will "detect" that parent OU is missing and it will generate the CSEntry object of "organizationalUnit" type in the target management agent. Consequently the organizational unit object will become (and remain) connected to the user (person) MVEntry object. All consecutive provisioning attempts of any other user objects to the previously dynamically-generated OU will be successful.
However problem could arise when "first" user in this dynamically generated OU is ready to be de-provisioned. Since the OU object is still connected to that user object de-provisioning routine could de-provision the organizational unit object along with the user object, which will leave all other users, provisioned to the same OU, without a "parent". To avoid this unwanted condition provided code example disconnects an "organizationalUnit" object from "user" object during next synchronization cycle of the Sync Engine. It is important to make sure that your configuration is not set to leave disconnectors of the "organizationalUnit" type as "normal disconnector".

Administrators are strongly encouraged to review de-provisioning logic for all types of objects while implementing this dynamic OU provisioning routine.

You can find code for the "Dynamic Organizational Unit provisioning with ILM 2007/MIIS 2003" here

Phone Formatting

In many of my Identity Management (IdM) projects I am facing predicament of "dirty data". The term of "dirty data" is used to describe incorrect or misleading data residing within a data-source.

Self-service data-sources (such as web-portals, phone directories, etc) are the biggest producers of inconsistently entered data, which is understandable in the scenario when any user is allowed to modify his/her data manually with little guidelines and data verification(s).

There are many deferent types of user-provided data Identity Management professional will face; one of the most common data types that is "outsourced" for entering to the end-user is a user’s phone number(s). In the end all synchronized data sources could consume that data, which could lead to difficulties in processing, if/when application(s) expecting more consistent data format.

Here in North America we are lucky to have uniformed phone numbering plan (from programmer stand-point) , known as North American Numbering Plan (NANP); NANP makes parsing of the phone number relatively easy; This article covers only North American phone number format and does not attempt to parse any other formats for any other phone systems. Direct application of this custom format provider to other types of phone numbers could result in unpredictable results. However you can extend this code to process other types of the phone numbers by adding methods that would recognize formats of the phone numbers specific to your local phone system. Good example would be French phone system, which is persistent in its numbering rules and therefore can be quantified by format provider relatively easy.

In the library that I’ve posted on Code Project you can see how you can brush-up the phone number that was not stored in uniformed manner.

You can find the Lost and Found Identity – North American Phone Formatter here

Starting my Blog

Ladies Gentlemen

After years of silence I’ve decided to dedicate some time for my blog. It’s new and painful experience for me… LOL

I’ll be posting some of my Identity Management related articles here. After years of working on IdM arena it’s time for me to post some of my work and make it public.

I’ve already created several projects on CodeProject server and will be referencing some of that work here.