Mapping Tivoli- Lessons Learnt
Image via CrunchBase
I was at a client doing some Identity mapping. They have TIM Tivoli, which had to be mapped against their people soft data. I needed to pull their usernames (eruid), employeeIDs (eradEmployeeID) from objectclass eradaccount (AD stuff), I also had to get their email accounts (which are under a custom objectClass (did not come from AD originally). I was trying to write a VBScript to pull everything. But Unfortunately all the code that’s out there on the web is very AD specific (AD Provider, adspath etc) and was not able to properly run a query from a VBscript to hit LDAP.
So I emailed Charles Ahart a blogger who blogs about his Tivoli experiences. And I tell him about my problem. I mentioned I was trying to pull this data into SSIS to map against their PeopleSoft Employee ID. So VBScript or Vb.net code would work. I was also given access to their DB2 database. That thing is crazy I could connect from SSIS to it, but the data is just all over the place. While I needed just 3 attributes It was so difficult to track them down. Even the Client’s TIM dba couldn’t figure it out. So I thought if I can’t do this with a script, I will have to do it through running a query against the DB2. I think the script would be an easier route to take.
Charles Responded:
Yes TIM is quite a “bear” when you try to dig into it. It’s not usually a good idea to interact with TIM at the DB2 layer except for maybe doing some historical reporting against the transaction database. Talking to the LDAP DB2 directly is dangerous. If you are looking to read data you could make LDAP calls to get what it is you need or you can write a web service to talk to TIM via the Tivoli API’s. All the Tivoli Java Docs are available on the TIM server under /opt/itim/extensions/examples.
If you need to just read some attributes then LDAP calls would be easier.Also, TIM comes with TDI which is a very powerful tool for moving data around. You could leverage that as well. Chances are if they are running TIM then they have licenses for TDI and this is a very easy tool to run from your desktop or server. It has many connectors already built for LDAP, JDBC, file system connectors with built-in parsers, and much more. You can code JavaScript in that tool to pull data very easily from one system to another.BTW, TIM comes with connectors to Peoplesoft, so you could integrate Peoplesoft directly with TIM or you could be using TDI to connect the two. I’m not sure what data your trying to move from where to where.To see what’s under the hood in TIM, you will need access to login to the TIM LDAP and point an LDAP Client at the TIM Box. There are TIM Identities (TIM Profiles) which are the Persons in the TIM System. These reside in a subtree like the following:
ou=people,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
There will be another entry for each person’s accounts under the following subtree:
ou=0,ou=accounts,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
In this subtree you will find all the user accounts which are linked to the account owner. So the owner attribute for each account references the DN value for the TIM Person who owns that account. All the attributes for an AD user would be contained in the AD account entry for that use.
http://www.google.ca/search?hl=en&q=www.experts-exchange.com%2FDatabase%2FLDAP%2FQ_23186562.html&btnG=Search&meta=
(click on the first link, and scroll down to the bottom). This page also explains why VBScript wont work. I had figured out the LDAP queries using the LDAP Browser and Editor. It was just really frustrating that I couldn’t make it work in VbScript. The explanation given on that page is
The problem I was encountering finds its roots in the limits of ADSI. As per MS article 251195, ADSI uses the subschema information to expose the proper interfaces for a given class, and to retrieve attributes in the correct syntax from the property cache.
If ADSI is unable to locate or properly validate the subschema information, it uses the default LDAP version 2 schema. Because LDAP version 2 servers do not expose a subschema, ADSI maintains schema information internally about many standard attributes and classes. If ADSI uses the default version 2 schema, it does not have access to nonstandard schema information, including custom classes or attributes that have been created on the server.
In a future post, I’ll share the Vb.net code to run LDAP 3.0 queries (works for non-AD LDAP interfaces) and how to use that in SSIS using Variables in a manner that will help make the script reusable.
On a Final Note I said to Charles:
“It’s interesting to know IBM has so many tools but that’s such a catch 22, they have so many tools its hard to know as a non-IBMer what the usage and flexibility is. ”
His response:
Your right about the IBM tools. There are so many and while it is highly extensible, it can be quite challenging to get these products to stand up initially. Their Identity Management system has come a long way with TIM 5, but I still think that the UI leaves something to be desired. But hey, doing Identity Management products is only partly about the technology anyways.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=2da10bc7-1344-42f0-b71b-433d8c963749)
