Monthly Archives: September 2009

Tivoli Directory Integrator – Part 6: Updating An External LDAP Server From Domino

By Marie Scott and Thomas “Duffbert” Duff

In this installment, we’re going to delve a little deeper into Tivoli Directory Integrator by demonstrating how to update an external LDAP server with Domino Directory [Duffbert - Notes Address Book aka NAB or names.nsf using LDAP – for us developer types] data using a TDI LDAP connector.  This particular AssemblyLine will also stretch our TDI skills by require some JavaScript to parse the Domino data into the format needed by the external LDAP server. 

Before we begin this process, we need to have a Domino server that is running the LDAP server task.  We’re using an LDAP type connection for Domino for our demonstration.  We only need reader access to the Person documents in the Domino Directory because we are not updating fields in those documents.   Likewise, we are going to update records in the external LDAP directory, so we need the appropriate login credentials and update authority in the LDAP tree.  We are not deleting attributes, so we do not need delete authority in this example.

 In this particular AssemblyLine, our goal is to update some Domino-related attributes in our external LDAP server.  We’re including these values in our external LDAP entries for each person, so that Domino can be later configured to use the external LDAP as the source for HTTP, IMAP, and Sametime authentication. [Marie – Domino admins out there will note that Directory Assistance will be used on the Domino side for authentication…this is a handy trick!  Duffbert – yeah, yeah… get to the good stuff!] The attributes have already been added to the schema on the external LDAP server, as they did not previously exist.  What is important to note is that we need a unique key to match the records from Domino to LDAP.  In our example we use unid (which is an LDAP default identifier) and an employee id number.   The AssemblyLIne does not require two keys to link data attributes, but in this case we are using two, and as you’ll see the AssemblyLine will allow you to use multiple keys.

The attributes we’re going to work with are the following:

  • $dn
  • DominoUserAbbrev
  • DominoUserName
  • displayname
  • mailfile
  • mailserver
  • sametimeserver
  • employeeid
  • uid 

    To get started we create a new TDI Configuration.  

    tdipart06-11new

    Next we create a new AssemblyLine.

    tdipart06.22new

    Now we’ll create a new Connector called DominoLDAP in “Interator” mode.

    tdipart06-33new

    So now we have a Domino LDAP connector.  Next, we’ll create our connector to our external LDAP server.  This will work exactly the same as the one we just created, but we’ll call it EDIRLDAP and set it up as an “Add Only” Connector.

    tdipart06-44new

    So how do we connect to our Domino server via the LDAP connector?  We connect using the LDAP url and port of our Domino LDAP server, with a userid and HTTP password that has access to read the Domino Directory. [Marie – we can also set up an SSL connection by selecting that option.]

    tdipart06-5b

    We’re also limiting the LDAP search filter by using the objectclass=dominoperson.  This will give us only those attributes in the dominoperson schema.

    We use the same method to connect to the external LDAP by connecting to the specific LDAP server and limiting the search base and search filter based on what we’re going to update in the LDAP schema.

    Once we set up our login information, we’ll want to make sure we can actually “talk” to the servers via TDI.  To do this, we use the Establish Connection button (the little plug)

    tdipart06-5c

    If all the information is correct in the previous step, we’ll see that a “Connection Established message.

    tdipart06-5d

    Now, we can click the “Read the Next Entry” button (the little triangle) to cycle through the entries in the actual LDAP directory.  This will allow us to view real “live” data to confirm the formatting.

    So to recap – we’ve created a new AssemblyLine, created two new connectors, and tested the connections.    What’s next?  Now we want to add the connectors to the appropriate places in our AssemblyLine. We can do this by dragging and dropping the “DominoLDAP” connector over to our AssemblyLine Feed indicator.  Add the External LDAP connector – as our AssemblyLine “flow” by the same method.

    tdipart06-2c

    How do we pick fields we want to work with?  A couple of things to keep in mind – the Feed connector will have an INPUT tab and your Flow connector will have an OUTPUT tab.  These tabs are where we work with selecting our data fields also known as Work Entries:

    tdipart06-55new

    Okay, these next steps are a little hairy so pay close attention.  On the FEED/INPUT Map – we have WORK Attributes.   These are the select group of data fields from our Domino Directory.  Some of these Work Attributes actually exist in the schema of the Domino Directory, and we can use them as is, so we can drag and drop them from the Schema View over to our Work Attribute list. 

    tdipart06-66new

    Once we’ve selected a Work attribute, say for example “givenname”, if we know that we’re going to use that value as is, we can enable that in the Attribute Map settings (the Attribute Map is displayed when a Work Attribute is selected individually). So we’ve selected the Work Attribute by name in the Attribute Map as well as selected “Enabled” and type as “Simple”.

    tdipart06-77new

    Now we do need to do some parsing, as the format from Domino does not match that of the LDAP results as we showed in the table above.  The method for making those changes involves pulling the data from the feed and making the change to the work items, and then parsing the data when it is output.  We’re going to use JavaScript to perform these operations.

    Let’s start with one of the Work Attributes – mailfile.  Because the data in the mailfile field from the Domino Directory needs to be parsed, we use JavaScript to change how the data appears.  We do this in the Attribute Map Setting by selecting Advanced (JavaScript).

    tdipart06-88new

    We also have some Work Attributes that don’t exist in the Domino Directory, but they will need to map to fields in our external LDAP directory.  So we click the Add New Attribute button.  In this example we are going to add a Work Attribute called  “DominoUserName” that will use data from the Work Attribute called “$dn”, and we’re going to do some Advanced (JavaScript).

    tdipart06-99new

    Once we have completed updating both the Work Attributes (Feed) and Connector Attributes (Flow), we should have the following fields with the appropriate coding:

    $dn

    Work Attribute

    No advanced mapping;Enabled

    DominoUserAbbrev

    WorkAttribute

    temp=conn.getString(“displayname”);

    ret.value=temp.toLowerCase();

    DominoUserName

    WorkAttribute

    temp =conn.getString(“$dn).replace(“,”,”/”);

    ret.value=temp.toLowerCase();

    givenname

    WorkAttribute

    No advanced mapping;Enabled

    Mail

    WorkAttribute

    No advanced mapping;Enabled

    Mailfile

    WorkAttribute

    ret.value=conn.getString(“mailfile”).replace(“\\”,”/”) + “.nsf”;

    MailServer

    WorkAttribute

    ret.value=conn.getString(“mailserver”).replace(“,”,”/”);

    Sametimeserver

    WorkAttribute

    ret.value=conn.getString(“sametimeserver”).replace(“,”,”/”);

    ssn

    WorkAttribute

    No advanced mapping;Enabled

    uid

    WorkAttribute

    No advanced mapping;Enabled

    $dn

    Connector Attribute

    ret.value=”uid=” +work.getString(“uid”) + “,ou=people,org=domain”

    DominoUserAbbrev

    Connector

    Attribute

     

    ret.value=work.getString(“DominoUserAbbrev”);

    DominoUserName

    Connector

    Attribute

    ret.value=work.getString(“DominoUserName”);

    givenname

    Connector

    Attribute

    No advanced mapping;Enabled

    Mail

    Connector

    Attribute

    No advanced mapping;Enabled

    Mailfile

    Connector

    Attribute

     

    ret.value=work.getString(“MailFile”);

    MailServer

    Connector

    Attribute

     

    ret.value=work.getString(“MailServer”);

    Sametimeserver

    Connector

    Attribute

     

    ret.value=work.getString(“sametimeserver”);

    eduPersonID

    Connector

    Attribute

    No advanced mapping;Enabled

    uid

    Connector

    Attribute

    No advanced mapping;Enabled

    So how do we “join” the two separate sets of data?  We link them via our keys and the Link Criteria tab on the AssemblyLine Flow attribute.  As we said we’re going to make sure that our entries in the External LDAP server are updated only when the unid and $unid are the same AND when the employeeid is the same.  So we’ll link those attributes on the Link Criteria.

    On the Flow Object – EDIRLDAP – go to the Link Criteria tab.  Click on the Add New Link Criteria icon (the little chain) and select “uid” as the connector attribute, “equals” as the operator, and “$uid” as the value.

    tdipart06-3b

    tdipart06-3a

    uid is the value in the Domino Directory, and $uid is the value in the external LDAP Directory.

    So we go ahead and create a similar link criteria for “employeeid” as the connector attribute, “equals” as the operator, and the attribute that contains the employeeid in the external LDAP directory.  [Marie: Attribute and value names don’t have to match when establishing them as link criteria.]

    Now that we’ve set up linking, and customized our Work/Connector Attributes, our Work Entry view should look something like this:

    tdipart06-55new

    Whew!  Now would be a perfect time to save the AssemblyLine configuration as we certainly wouldn’t want to have to rebuild all those connections.  And a word of caution before we proceed to the next step… As with any system, you want to make sure that you have a test environment to work with before you put this into the LIVE REAL WORLD!  TDI is very powerful, and could easily wipe data from the feed or the flow ends of the AssemblyLine.  So please don’t take our names in vain and say that we didn’t warn you!

    So we’re ready to start our AssemblyLine and see how we’ve done.  We’re going to select Standard as our Run Mode and will click the start button to complete.

    tdipart06-new3

    A tool that may come in handy when you’re working with LDAP entries on different types of servers is an LDAP browser, so you can review your data.  One we’ve used before is the Softerra LDAP Browser (they have a free version!).

    Here’s one of our diagrams to display what we’ve done:

    tdildapexample

    Using this example, you can now synchronize your Domino LDAP directories to all your other external LDAP directories without having to invest in an expensive tool to do so.  That should make you very popular with your boss, and may be a leverage point when you ask him for permission to go to Lotusphere!

  • No, no! Say it’s not so!

    Sometimes you can’t always believe what you read.  For example, The Commonwealth Times, the student newspaper at Virginia Commonwealth University, posted the following article. If you take the content for what it says, it does sound like the entire university is moving to Google.  However, this is not the case.  Then another blogger posted this blog.  And in the context of his blog he made some assumptions which really weren’t accurate.  I responded to those assumptions in kind.

    As a result, I’ve learned several valuable lessons.  Make sure that content posted on the web is accurate.  Secondly, don’t assume that the author is an expert in the field of the content material or that they have vetted their sources.  With today’s web commentary — that is not always the case.  And for some reason Google seems to hit a hot button with everyone these days — whether it be with migration from one email system or another or Google vulnerabilities, etc. etc., we all like to find something newsworthy to post about Google.  Well maybe we need to step back and make sure the information we have is accurate.  I include myself in that “we” as I have blogged about Google as well.  I would also caution those blogging as to the reasons why a company moves to Google.  With firsthand experience, I can say that the decision making process to move to any new messaging platform is complicated and not as straightforward as it may seem.  So the collective “we” should not shoot those managers who have had to make those difficult decisions or those technologists who have had to implement those decisions in the foot, because who knows “we” might be next.

    A Lotusphere Anxiety Attack

    Hi my name is Marie, and I’ve had a Lotusphere anxiety attack.  Well, truth be told I’ve had several of them.

    For the first year in a long time, it may not be a given that I will be able to attend Lotusphere.  Now for those of you who have only attended one or two Lotuspheres this may seem rather silly.  Having an anxiety attack? Come on now.  But given that Lotusphere 2010 would be my twelveth Lotusphere, it truly has become an annual event.  My year would not be complete without the “family reunion” in Orlando.  As the Virginia State government budget is in crisis right now, all travel expenditures are being reviewed. My fingers are crossed that my trip will be approved.

    Secondly, for the first time I am working on some abstracts to submit as a speaker.  While I have fantastic possible co-speakers, I’m still so, so nervous about being on the other side of the stage if accepted.  It sounds like there is a lot of great material going to be submitted this year, so we should have the best Lotusphere yet!

    Thirdly, Lotusphere registration is later than usual.  And don’t we all like to have our registration in hand by now?  Some of you may not remember those years when you had to be poised the ready on the first day because registration filled up.  Again…why should I be nervous?  I just am!!!

    In sum, in case you can’t tell — I am looking forward to Lotusphere this year, probably more so than any other year.  As a new blogger, I can’t wait to meet all the folks I’ve met through my blog and through Twitter.  And I’m also anticipating all the great content we have to look forward to with 8.5.1 and beyond!

    January 17, 2010 here we come! :-)