Three specific Internet Services were enhanced through the use of an LDAP server. They included: e-mail servers using Sendmail, Usenet or Network News servers using InterNetworkNews (INN), and file transfer servers using Samba[14] (PC NetBIOS file system on a UNIX host) and Expect[13] (an interactive process scripting language for UNIX).
As its basic function, the LDAP server provided a data storage facility which was easily accessible using a Perl script or simple modifications to supplied application configuration code (Sendmail). This avoided developing specialized databases with specialized program interfaces. Also, no fundamental changes in each of the Services were required.
The LDAP server also provided a central data-store, much as a traditional database, where many sets of information, such as a list of authorized Network News posters for a given internal or local newsgroup, a list of Internet hostnames associated with some specific services such as electronic mail and Network News, and a list of people within certain organizational groups which may be independent of the other lists, could be kept - regardless of their association with each other. In other words, there is no need for a specialized database just for electronic mail, and another one for Network News, and yet another one for the file transfer mechanism. At the same time, the data used for these enhanced Internet Services could be, and were, related to a specific user or entity. In the particular case of Sendmail, the LDAP server replaced one of the Sendmail user databases.
Another benefit to using an Internet Directory Service was the fact that there are multiple publicly available access methods, such as Frank Richter's Web500GW Web interface[11], Kartik Subbarao's ldaptool.html[18] for use with Web browsers, or one of the University of Michigan's specialized, yet freely available, interface programs (i.e., Wax500, Max500, Xax500). This meant that a commercial or proprietary program is not needed to use or access the LDAP data, which means easy maintainability and reduced costs.
At the same time, access to specific data items within the server can be easily restricted without writing specialized access application programs. Using LDAP Access Control Lists (ACLs), the appropriate access permissions are established for some of the data used in these facilities.
While each of the three services enhanced with LDAP could have provided its own facility to store and retrieve some of the user/service data required, this would have led to extra maintenance for each service. Using the Internet Directory Service method, very little maintenance is required to store and obtain the necessary data for the enhanced services. After the installation or addition of the relatively small sets of code for each service to access the LDAP data, all maintenance is then left to just the LDAP service itself.
A late addition to this project is a simple Perl script to formulate an LDAP query specifically looking for information about a LAN Administrator, and then display the result in a simple table. This required a locally installed portion of the LDAP suite (LDAPSEARCH) to perform the actual LDAP work. The Perl script's main function was to take the user's input, generate the LDAPSEARCH parameters, execute the LDAPSEARCH program, and display the selected output in a more user-friendly format.
Another late addition to this project is a simple JavaScript function for a Netscape V4 browser (which has built-in support for LDAP) that implements a simple but effective search for LAN Administrators based on one of several criteria. This is another example of a relatively easy method to extend the use of and access to data stored in an Internet Directory Server.
Lastly, this report does not discuss the implementation of network and data security, including passwords. Some general comments on security, however, can be found in Section 11.