How many corporate LDAP directories does your company have? Even in today's world of open standards, often the answer is two or more. This can happen for various reasons: company acquisitions, projects developed by different departments, legacy applications, or product incompatibility with corporate standards. To build a real SSO (single sign-on) solution, it is important to keep data synchronized among directories, but trying to manually synchronize heterogeneous directories can be maddening. IBM Tivoli Directory Integrator (TDI, formerly known as IDI) can simplify this job.
The Lotus Engineering Solution Test team is dedicated to modelling a "first customer" experience by creating and running user scripts, workloads, and scenarios that simulate real user activity in an actual production site. To ensure our testing is as accurate and realistic as possible, we build large, complex environments consisting of multiple servers running different platforms, software, and other configurations. This requires us to maintain a number of LDAP directories and to keep them current and in synch. To do this, we rely heavily on Tivoli Directory Integrator to synchronize LDAP directories. We can also use it to generate directory information in various formats, including HTML and XML.
This article explains how Tivoli Directory Integrator can help your IT organization streamline LDAP synchronization tasks. We assume that you're an experienced system administrator.
Our example corporate environment
Imagine a business with 10,000 employees, located in various cities. The corporate LDAP directory is Microsoft Active Directory 2000 (MSAD). This directory contains a record for each user and is actively used by other corporate applications. About half the users also use Lotus Notes and for several years have been using Lotus Notes mail (both via the Lotus Notes client and through a browser using Domino Web Access), Lotus Team Workplace (QuickPlace), Lotus Instant Messaging (Sametime), and other Domino applications.
The IT department recently deployed release 2.0 of Lotus Workplace, using MSAD for authentication. This has prompted the Notes users to request the ability to access Domino information and applications from within Lotus Workplace. In response, the IT department has designed new pages that use the Lotus Collaborative Components Portlets and the Collaboration Center Portlets to allow access to Domino servers.
Lotus Workplace is built on WebSphere and can therefore use LTPA tokens for authentication. So can Lotus Domino, but users in our mythical company find that they are still asked to authenticate by the Domino server (or worse, access to the Notes mail file is not granted). Access to other Notes/Domino applications is granted if the ACL for default access is set to Reader or higher. This demonstrates that SSO is configured correctly, but that the link between the MSAD record and the Person document in the Domino Directory is still missing.
Determining which credentials are used
To verify which credentials are being used to connect to Lotus Domino, the IT department can create a new database on the Domino server (for example, debugger.nsf) consisting of a page with two computed text entries. One has the value of @UserName to show the credential. The other has the value of @Text(@Now). (This accommodates the fact that @Now changes every second.) This prevents the page from being cached by the browser, which is useful when testing changes in real time. Don't forget to set the Database Launch option to open the page when the database is opened with a browser. The result is something similar to this:
You are logged is as: CN=BExternal User1/OU=Burlington/OU=Lotus Engineering/ OU=Solution Test/DC=westford/DC=notesdev/DC=ibm/DC=com The timestamp from the server is 07/08/2004 03:55:52 PM |
What Lotus Domino shows as the user name is the MSAD LDAP DN sent in the LTPA SSO token:
CN=BExternal User1,OU=Burlington,OU=Lotus Engineering, OU=Solution Test,DC=westford,DC=notesdev,DC=ibm,DC=com |
The Domino user name format uses slashes and not commas.
Manually updating a Person document
Rather than add the Domino representation of the LDAP DN to the ACL of each database and to groups in the Domino Directory, it is much easier to add the DN to the Person document. For example, if the user BExternal User1 in MSAD is named BNotes User1 in Domino, you can modify the Person document by adding the line CN=BExternal User1/OU=Burlington/OU=Lotus Engineering/OU=Solution Test/DC=westford/DC=notesdev/DC=ibm/DC=com to the User name field:
Figure 1. Person document User name field
When the user BExternal User1 logs in to Lotus Workplace to access a Domino database, he is recognized by Lotus Domino as if he were using his Notes ID, allowing transparent access to the various databases. However, applications that use custom queries to the directory and don't use the DN to identify the user still may not work. One example is the Domino Web Access (iNotes) portlet.
To verify which attribute these application use, it is possible to enable LDAP debugging on the Domino server console by issuing the command set config ldapdebug=7. In the case of the Domino Web Access portlet, instead of querying the directory for the DN, the sAMAccountName attribute (equivalent to the User logon name in the MSAD User Properties dialog box) is used to query Lotus Domino:
Figure 2. User Properties showing query credentials
By adding the sAMAccountName (in this case, Beuser1) to the User name field in the Person document (shown in red in Figure 1), you allow the Domino Web Access portlet to correctly find the user's mail file and to authenticate with Lotus Domino.
Using Tivoli Directory Integrator to update multiple Person documents
Updating one document manually is a quick way to verify whether or not a solution works, but updating thousands of documents is a different matter. For this purpose, our fictitious IT manager needs a tool that provides automatic updating of Person documents in Lotus Domino with the information present in MSAD without manual data entry (to avoid typos and mistakes which would generate calls to the help desk). The process should require little programming, but still be powerful enough to evolve with the future company needs.
IBM Tivoli Directory Integrator is the perfect tool for this task. It allows the administrator to connect remotely to MSAD using LDAP, to select the records using filters, to extract the data, and to update the corresponding Person document in the Domino Directory with just a few lines of code.
The first step is to configure a TDI connector to the MSAD using LDAP by providing the host name, the credential to use, the Search Base, and the Search Filter criteria to use to select the records:
Figure 3. TDI LDAP Connector
TDI discovers the LDAP schema automatically, which allows the administrator to select the attributes needed ($dn, cn, mail, sAMAccountName). The first attribute you need to create is the MSAD DN in Domino format. Do this by replacing "," with "/". TDI uses JavaScript by default (but you can use VBscript, Perl, or other languages if you prefer). It is, therefore, easy to find and reuse existing functions on the Internet as well as other resources (such as the extensive TDI documentation) that can be used to complete tasks. Figure 4 shows the code for the new attribute dnForDomino:
Figure 4. Code for dnForDomino attribute
The code for the attribute DominoTarget is used to build a string representing the name of the user in Lotus Domino (BNotes User1) from the name in MSAD (BExternal User1):
gn = conn.getString("givenName");
sn = conn.getString("sn");
x = new String(gn);
x = x.replace("External", "Notes");
ret.value = x + " " + sn;
|
Any attribute that provides a unique match is suitable (such as employee number or email address) as long as it is available in both directories.
Similar to the MSAD connector, the Domino LDAP connector is set up with parameters to connect to the Domino server via LDAP:
Figure 5. Domino LDAP connector
The Domino LDAP connector uses the Link Criteria to generate a link from the current MSAD record to the one you want to update in Lotus Domino:
Figure 6. Link Criteria
The Output Map defines the update activity to perform on the Person document. This consists of adding the dnForDomino and sAMAccountName attributes from MSAD to the cn attribute in Lotus Domino:
Figure 7. Output Map settings
Before running the activity to update the Domino Directory, you can write all records to a text file. The text file is useful to verify that the code is functioning as required.
Alternatively, you can modify the LDAP search filter and apply the changes to only a subset of the records before proceeding with the full batch process:
Figure 8. LDAP search results
As you can see, Tivoli Directory Integrator allows IT departments to synchronize LDAP directories simply and programmatically. However, what we've described in this article is actually just one relatively simple example of Tivoli Directory Integrator's capabilities. Tivoli Directory Integrator can do more than just update a directory, it can keep directories synchronized, migrate data, extract data from legacy systems, and generate HTML, XML, CSV, and much more.
- For detailed product information about IBM Tivoli Directory Integrator, see its product page.
- If you want to learn more about the power and versatility of Tivoli Directory Integrator, visit the IBM Redbooks site.
Ivan Dell'Era left Italy in the 1990's to join Lotus/IBM in Paris, France. After travelling over 500,000 miles around the world helping customers, he has found his final destination in Massachusetts, USA. When not testing Lotus and IBM products, Ivan enjoys spending time with his growing family and his two dogs, experimenting with digital photography, searching the Internet for hi-tech bargains, and helping friends with their technology questions.
