V4R4 Directory Services is based on the Lightweight Directory Access Protocol (LDAP)

and allows email addresses to be selected from the LDAP data repository residing on the AS/400. The V4R4 Directory Services server can be populated with email addresses from the AS/400’s System Distribution Directory (SDD). The AS/400’s Directory Services (LDAP) server can then provide an address book to Windows 9x and Windows NT workstations running an LDAP-compliant POP client.

LDAP Overview

Let me take a moment to define just what LDAP is. LDAP is an application-level protocol that uses TCP/IP and functions at the application layer of the TCP/IP stack model. (For more information on this model, see Daniel Green’s “Technology Spotlight: Inside TCP/IP Addressing,” MC, June 1998.) By functioning at the application layer, LDAP provides access to a common data repository.

LDAP is also a communications protocol that defines how the LDAP client and server transport and format messages when communicating with each other. LDAP is neither a directory service nor a server. However, when working with LDAP, the Directory Services server containing the data repository where data objects reside is often referred to as the LDAP server.

LDAP Client/Server Interaction

An LDAP client establishes a session with an LDAP server. (This process is called binding.) The client has to have a host name and port configured that will be used to connect to the LDAP server. The client also has the option of logging on anonymously; specifying a user ID, Distinguished Name (DN), and password; or using a DN obtained from a digital certificate. One thing to note about using LDAP with the AS/400 is that, on the AS/400’s Directory Server, sign-on to the Directory Services server is not associated with AS/400 authority methods. The LDAP server on the AS/400 acts as a network directory and, unlike the SDD, not as an AS/400-specific directory.

The Directory Server uses access control lists (ACLs) defined on the LDAP directory for authentication purposes in the directory structure. ACLs either are defined for

each object in the Directory Services directory or inherit their authority from the objects’ hierarchical parents. After an LDAP client has logged into the LDAP server, the LDAP data repository can be searched, modified, added, or deleted, assuming that the ACL permits this. You can perform searches on either all or only parts of the Directory Services database by using a variety of Qshell commands, such as ldapadd, ldapmodify, ldapdelete, ldapmodrdn, and ldapsearch.

LDAP Directory Structure

An LDAP directory is a data repository that has a defined structure. In this case, LDAP provides access to a Directory Information Tree (DIT) structure. The DIT can be flat or spanning and is composed of entries, also known as objects. You typically use a flat DIT when the LDAP Directory is relatively small and the objects are not connected into either a global corporate or Internet DIT structure. A spanning DIT would consist of objects organized in a multiple-level hierarchy. For example, the top level would contain the United States; the second level would contain Company 1, Company 2, and Company 3; the third level would contain an entry for each city in which each company has offices. Each object is defined by attributes that have an associated type that adheres to specific syntax rules. In addition to attributes, each directory has a schema, which is a set of attribute type definitions and object class definitions. A schema basically defines the rules that govern the structure and contents of the DIT. The LDAP server uses schemas to determine whether or not add, modify, delete, compare, or search operations can be performed. If you want to see the parts of LDAP mentioned here, you need to look in the following places:

• Schema files for the AS/400 are located in the root AS/400 Integrated File System (AS/400 IFS) structure, /QIBM/ProdData/OS400/DirSrv.

• Object class definitions are located in the files IBMOC.txt, SysOC.txt, and UsrOC.txt.

• Attribute type definitions are located in the files IBMAt.txt, SysAt.txt, and UsrAt.txt.

To access these files, use Client Access/400’s Operations Navigator. Each object in the DIT has both a DN and a relative distinguished name (RDN). The DN is analogous to specifying the entire path to a program (e.g., /usr/bin/config/runtest.c) instead of residing in the config directory already and issuing cd config. The RDN defines each object in a hierarchy relative to its parent. The DN is built based on combining all the RDNs. So, if o=TheCompany, ou=Information Technology, and cn=Mr Administrator, the RDN would be cn=Mr Administrator and the DN would be cn=Mr Administrator, ou=Information Technology, and o=TheCompany.

Mapping the SDD to LDAP Attributes

SDD parameters are mapped to their counterparts in the LDAP directory. Mapping follows a convention in which SDD Directory Field=LDAP Attribute. The relationship of the mapping follows this convention: AS/400 User profile=uid, Descriptions=description, etc.

Industry Acceptance

The beauty of the AS/400 is that LDAP Directory Services provides cross-platform interoperability. This is true because IBM, Netscape, Microsoft, and Novell are all involved with the implementation of LDAP. The reason software developers are so anxious to integrate their products with LDAP is that LDAP serves as a common denominator of address books and repositories of information, including names, addresses, employee numbers, and information about software and hardware components. No one wants to get left out in the cold! Just to give you an idea of how involved each of these companies is with LDAP, consider the following facts: IBM provides LDAP directories on OS/390,

OS/400, AIX, and NT, and Netfinity for AS/400 uses an LDAP directory to inventory workstation information for nodes on the network.

Where Does SMTP Fit In?

You can store email addresses on the AS/400 in either the SDD or the Simple Mail Transfer Protocol (SMTP) system alias table. Prior to V4R4, many AS/400 installations would configure users’ email addresses and keep them in the SMTP system alias table. The option to convert these email addresses to the SDD was available, but LDAP synchronization was not always a consideration.

In V4R4, the SDD automatically exports to the LDAP directory when user information is changed within the SDD. By using either OS/400 SDD commands such as Work with Directory Entries (WRKDIRE) or AS/400 Operations Navigator, email information is published to the AS/400 Directory Server when modifications are made. Think of it this way: The SMTP system alias table links to, but is not part of, the SDD, so the administrative changes you make to the SMTP system alias table by using the Work with Names for SMTP (WRKNAMSMTP) command are not updated in the Directory Services directory. However, in V4R4, use the Convert SMTP Names (CVTNAMSMTP) command to convert email addresses from the SMTP system alias table to the SDD so that changes are updated.

When implementing LDAP Directory Services in V4R4, you should consider converting email addresses from the SMTP system alias table to the AS/400’s SDD. Keep in mind that some installations have written custom programs to write to the SMTP system alias table, so if you fall into this category, contact the IBM Support Line to discuss pros and cons of converting the SMTP system alias table to the AS/400’s SDD. One other caveat: Using WRKNAMSMTP is a one-way conversion. After you convert the SMTP system alias table to the SDD, SMTP user and domain information resides in the SMTPAUSRID SMTP and SMTPDMN user-defined fields within the SDD. (In other words, you can’t go back.)

Configuring V4R4 Directory Services on the AS/400

Before beginning your LDAP configuration of the V4R4 Directory Services server on the AS/400, note that this article is specific to V4R4. Although Directory Services is available on V4R3, the implementation involves considerations that this article doesn’t address. Do not attempt to use the steps in this article to configure V4R3 Directory Services on AS/400. Contact IBM’s support line for specific instructions for V4R3.

Before you get started, make sure that you have V4R4 installed. All the latest TCP/IP stack, LDAP, Sockets, Mail Server Framework (MSF), and SMTP PTFs should be installed, too. Review Knowledge Base Document 11984042 (www.as400service.ibm.com/) for the latest TCP/IP-related PTFs, and, when configuring the LDAP server through Operations Navigator, use IBM AS/400 Client Access Express for Windows V4R4M0 with service level SF58121 or later. In addition, ensure that the Windows operating system running IBM’s Client Access Express has a current Microsoft Service Pack installed. You may also want to review “Getting started with AS/400 Directory Services” at the IBM AS/400 Information Center
(www.as400.ibm.com/infocenter)
.

Installing and Configuring LDAP on the AS/400

The following are prerequisites for running LDAP on your AS/400:

• The user profile configuring OS/400 Directory Services must have *ALLOBJ and *IOSYSCFG authority.

• If the AS/400’s relational database has never been configured, the name for the system’s local relational database (RDBM) may be required using the Work with RDB Directory Entry (WRKRDBDIRE) command. The AS/400’s system name is used by default.

• Ensure that 5769SS1—OS/400 Directory Services is installed by using Display licensed programs (option 10) from the Work with Licensed Programs menu.

After you ensure that you have met the prerequisites for LDAP, check that TCP/IP is correctly configured with a host and domain name as well as two entries in the host table, one for the LDAP server’s fully qualified domain name and another for just the domain name. Use the Change SMTP Attributes (CHGSMTPA) command to make sure that the SMTP attributes are set to the proper user ID delimiter for those shops that don’t have SMTP information configured for the related SDD entries.

After you’ve verified that TCP/IP and SMTP are correctly configured for LDAP, you can use Operations Navigator (OpsNav), as shown in Figure 1, to access the directory server. Ensure that the status of the directory server is Stopped. Right-click on the directory container and select Configure. A wizard will request that you create the library in which the LDAP directory will reside (OpsNav suggests /QSYS.LIB/DIRSVR.LIB). The administrator of the LDAP server will be defined in the Name parameter; by default, the value is CN=Administrator.

Define and confirm the administrator’s password. At least one suffix will need to be configured. One possibility is to use the name of your company or another meaningful name. Right-click on the Directory Server and select Start from the Properties menu. To refresh the Operations Navigator screen to ensure that the Directory (LDAP) Server is started, click on View and select Refresh. The library structure that will contain your DIT has now been created in the AS/400’s DB2 database.

To populate the data repository on the Directory Services server, select the system name being configured for LDAP, right-click on the system name, and select Properties. Then, as shown in Figure 2, click on the Directory Services tab. For V4R4, select User from the information box. Now click on Configure. As shown in Figure 3, the Directory Services publishing page will appear. Ensure that the Directory server parameter value is correct. Select the pull-down menu for the Under DN parameter. Select the appropriate DN. In this example, the DN would be o=MyCompany. Ensure that the DN for the server administrator is correct; the default DN is cn=administrator. Type in the password and click on the Verify button. If the directory path does not exist, you will be prompted to create the path. For publishing to be successful, the directory path must be created. Click OK on the dialog box that pops up stating, “Directory Services setting verified successfully.” Finally, click OK twice to finish the task.

Troubleshooting

The Directory Server on the AS/400 runs in subsystem QSYSWRK and is named QDIRSRV. Ensure that QDIRSRV is active in QSYSWRK by either using Operations Navigator or issuing the Work with Active Jobs (WRKACTJOB) command. If issues arise, look at the QDIRSRV job log or spool files. In V4R4, certain SDD
entries—including SDD entries containing *ANY, QSECOFR, QDOC, QSYS, etc.—do not get published. If two users have SDD field values that cause creation of duplicate DNs, these names will overlay each other. Ensure that users have unique names before publishing SDD entries to the AS/400’s Directory Server. Additonal information can be found at the AS/400 LDAP Web site at www.as400.ibm.com/ldap.

A need exists for mail clients to access a global address book. The advantage of using the Directory Services server on the AS/400 is that now a common repository for AS/400 email addresses can be transferred to mail clients by using the TCP/IP protocol. A mail client requests an address book, the LDAP Protocol facilitates the transfer, and the

AS/400 delivers a listing of email addresses. What could be easier? In other words, now your email addresses can be distributed to your intranet email clients.

REFERENCES AND RELATED MATERIALS

• IBM AS/400 Directory Services (LDAP) site: www.as400.ibm.com/ldap
• IBM AS/400 Information Center: www.as400.ibm.com/infocenter
• IBM AS/400 Technical Support: www.as400service.ibm.com
• IBM Client Access Web site: www.as400.ibm.com/clientaccess
• LDAP Implementation Cookbook, Redbook (SG24-5110-00)
• “Technology Spotlight: Inside TCP/IP Addressing,” D. Ellis Green, MC, June 1998
• Understanding LDAP, Redbook (SG24-4986-00)

Figure 1: You can use Operations Navigator to access the directory server.

Figure 2: Click on the Directory Services tab after you select the system name being configured for LDAP, right-click on the system name, and select Properties.

Figure 3: Clicking on Configure makes the Directory Services publishing page appear.