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:
To get started we create a new TDI Configuration.
Next we create a new AssemblyLine.
Now we’ll create a new Connector called DominoLDAP in “Interator” mode.
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.
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.]
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)
If all the information is correct in the previous step, we’ll see that a “Connection Established message.
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.
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:
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.
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”.
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).
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).
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 |
|
|
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 |
|
|
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.
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:
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.
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:
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!
