Directory Object Search

Have you ever wanted to perform an LDAP search in a workflow to check for … well let’s just say a duplicate UNIX UID.
In this example the account add workflow is checking to make sure the Unix UID is not in use by another account. The requirements in this instance are that UNIX UID can only be used once in a service. Once the duplicate is found the next step is up to you but in this case the account add was rejected.

First thing you have to do is expose the dataservices model. Add the following line to scriptframework.properties.

ITIM.java.access.dataservices=com.ibm.itim.dataservices.model.*

Example Script in Workflow Script Node:

This script node is from an Account Add workflow. The script gets the service DN and erposixuid from the new account. The service DN and UNIX UID are used to verify the UNIX UID has not been used before in the same service. The Directory Object Search will search ITIM’s LDAP as you can see from the search base. There are also a couple examples to get the account attributes.

/* Search the current service for an account with the same unix uid */

var myAccount = account.get();
var myPerson = owner.get();

var unixUidMatch = ‘false';
var dupAccountList = ”;
errorInd.set(‘false’);

/* Get Service DN */
var myServiceDN = myAccount.getProperty(“erservice”)[0];

var myInputPosixUid = myAccount.getProperty(“erposixuid”);
if (myInputPosixUid != null && myInputPosixUid.length > 0)
myInputPosixUid = myInputPosixUid[0];
else
myInputPosixUid = “unknown”;

if (myInputPosixUid != “unknown”) {
/* Search Accounts within Service for unix UID */
var searchFilter = ‘(&(erservice=’ + myServiceDN + ‘)(erposixuid=’ + myInputPosixUid + ‘))';
var searchBase = ‘ou=accounts,erglobalid=00000000000000000000,ou=XXX,O=XXX';
var base = new com.ibm.itim.dataservices.model.DistinguishedName(searchBase);

var params = new com.ibm.itim.dataservices.model.SearchParameters();
var search = new com.ibm.itim.dataservices.model.DirectoryObjectSearch();
var results = search.fetch(base, searchFilter, params).iterator();

while (results.hasNext()) {
/* Duplicate Unix UID Found */
var dirObj = results.next().getDirectoryObject();
/* Get Account Object */
var mySearchAccount = new Account(dirObj.getDistinguishedName().toString());

var mySearchEruid = mySearchAccount.getProperty(‘eruid’);
if (mySearchEruid != null && mySearchEruid.length > 0) {
mySearchEruid = mySearchEruid[0];
if (unixUidMatch == ‘true’)
dupAccountList = dupAccountList + ‘ ,’+ mySearchEruid;
else
dupAccountList = mySearchEruid;
}
unixUidMatch = ‘true';
}

OR

while (results.hasNext()) {
var dirObj = results.next().getDirectoryObject();
var myDupAccountID = dirObj.getAttribute(“eruid”);
if (myDupAccountID!=null) {
myDupAccountID = myDupAccountID.getValueString();
}
}

Tivoli Directory Integrator – Before Initialize – Add Date to File Name

I wrote a different TDI blog discussing the Before Initialize Hook.  That blog discussed setting the filter in an Iterator.  Here is another use for the Before Initialize Hook, this time in a File System Connector.  As I mentioned in prior PathMaker Group blogs Tivoli Directory Integrator (TDI) is a pretty neat tool that comes packaged with IBM Tivoli Identity Manager (ITIM) with a bunch of Connectors. This blog will relate to the File System Connector.

Have you ever wanted to build create a File System Connector that creates a file that has a unique value so the process can run multiple times a day or week and you don’t have to worry about overlaying the file?  This can be accomplished with the Before Initialize.  In this case the process will only run once a day so only the date is added to the end of the file name.

Read More»

Tivoli Directory Integrator – Before Initialize

As I mentioned in prior PathMaker Group blogs Tivoli Directory Integrator (TDI) is a pretty neat tool that comes packaged with IBM Tivoli Identity Manager (ITIM).  TDI comes out of the box with a multitude of connectors that are used to as the name says, connect to different sources.  One of the most common business processes where TDI is used is to extract data, transform the data and then load the data into different data source (ETL).  For an example, it is common to use TDI to extract account data from Active Directory using an LDAP connector.

Have you ever wanted to build a dynamic iterator filter that can be created when the assembly line is executed?  In the following example the assembly line uses an LDAP connector to iterate Active Directory.  The requirement is to find AD accounts where the “whenChanged” is in the last 5 days and AD entry should be a user account or a user contact and have a mail attribute.

Read More»

ITIM Provisioning Policy Priority

A provisioning policy in ITIM (IBM Tivoli Identity Manager) basically grants access and set entitlements to the ITIM managed services based on the provisioning policy membership.

Each provisioning policy consists of information and settings on the following tabs:

  • General
  • Members
  • Entitlements

Of course, there are factors to consider: Role Memberships, service selection policies and policy join behaviors to name a few but this blog is just looking at the value of the required priority attribute.

The priority setting is a required value on the General tab of the provisioning policy configuration.  This is a required numeric attribute and the lower the number the higher the priority of the Provisioning Policy.

Read More»

Tivoli Directory Integrator – On Multiple Entries

Tivoli Directory Integrator (TDI) is a pretty neat tool that comes packaged with IBM Tivoli Identity Manager (ITIM).  TDI comes out to the box with a multitude of connectors that are used to as the name says, connect to different sources.  One of the most common business processes where TDI is used is to extract data, transform the data and then load the data into different data source (ETL).  For an example, it is common to use TDI to extract Human Resources data and using a DMSL connector, send the data over to the ITIM Application for processing.

One of the main considerations in extracting data from different sources is the data.  The data values, the data relationships and attributes do not always exist as advertised.

For example:  The process pulls the employee information from SAP and then does a lookup to Active Directory using the employee number.  Active Directory is only supposed to have one entry for each employee.  “Supposed to” is the key word.  In some cases, there are multiple AD accounts for one employee.

Read More»
Page 1 of 212
© Copyright PathMaker Group 2014