Measuring how fast a Lightweight Directory Access Protocol server can reply to a mix of queries is one side of the coin for an LDAP implementation. However, you will also need to understand what these products offer by way of LDAP management tools and back-end services that can help them scale in a distributed environment.
Management tasks required on an LDAP directory server include starting and stopping the server, maintaining access-control lists for directory security, changing the schema, tuning performance parameters and setting up index types.
We found that pure LDAP products from iPlanet and Innosoft International Inc. are the easiest to manage. In part, this is because these two products don 't have much to them. Beyond the LDAP services, they both offer little to worry about, which translated into little to twiddle.
IPlanet 's Directory Server and Innosoft's IDDS come with miniature Web servers to handle most configuration tasks. Hardcore techie types can also opt to edit the configuration files or issue shell commands.
Directory Server offers a fairly elegant interface to certain functions, such as security access-control lists. When we managed to delete the Directory Server management Web server and cut ourselves off from the product 's main management interface, it was easier to reinstall the server to get the Web-based graphical user interface (GUI) back online than to figure out how to do certain things from the command line. Directory Server 's schema editor, while not the cleanest of the bunch, was a heroic effort for a Web-based application.
When it comes to X.500-based servers that ship with components more difficult to manage, Critical Path Software Inc.'s Global Directory Server and Computer Associates International Inc.'s eTrust Directory took a definite back seat to Siemens ' DirX.
DirX did the best job integrating LDAP into its overall server management interface. Although DirX has a command-line interface that we came to admire, the company 's GUI-based management tool had tremendous power. This was especially true when it came to difficult tasks such as schema modification.
CA 's eTrust Directory is largely managed with a command-line telnet connection to a local console, an approach that might work better if less day-to-day server tweaking and modification was necessary.
Critical Path 's Global Directory Server management was clean on the X.500 side, but the integration between the LDAP server and X.500 server was poor.
There were typographical errors in the LDAP schema generated at the Critical Path factory.
In the time frame of our tests, we were unable to properly fix all of them. It was easier to change our data than to hunt down all the details of the LDAP-to-X.500 glue.
We had a similar problem with Novell Inc.'s NDS eDirectory. The glue between the LDAP server and NDS made LDAP anything but transparent. For example, to change the NDS schema, you use the standard GUI, which launches a schema editor. It requires a different schema description entirely to change the LDAP schema, which then has to be manually mapped ¥ attribute by attribute ¥ from NDS to LDAP. Because NDS field types are different from LDAP field types, we had to check each field type manually to see if it was compatible and then come up with some accommodation for those that were different.
NDS eDirectory 's multiple management interfaces ¥ you have to use at least four separate ones to configure and manage the NDS eDirectory LDAP server ¥ are annoying to work with. NDS eDirectory is so tightly bound to the concept of operating system and enterprise resource management, that you cannot get away from it. For example, every object in NDS eDirectory participates in the operating system 's access rights security model: asking what can you do and who can you do it to. Enterprise resource managers looking to set up a directory-enabled network will welcome this comprehensive model, but when using NDS eDirectory in an LDAP environment, these attributes confuse the issue.
In general, though, Novell's Java-based Console One interface does not deliver on the company 's single point of management promise because there wasn 't a single interface. Instead there are multiple interfaces, all of which are launched differently, and had inconsistent ways of displaying and modifying information. We were also disappointed to discover that some basic tools that are included in NDS eDirectory on NetWare have been left out of the Windows NT version, such as the ability to control which attributes in the directory are indexed. Novell says these tools will be available in the next release of the product scheduled for later this year.
In terms of management, Oracle Corp.'s Internet Directory (OID) was more of a relief. We had been worried that you would have to be an Oracle Database Administrator to run OID. But in fact, OID hides the Oracle database very effectively from the LDAP manager.
You can 't be totally Oracle ignorant, though. Your LDAP directory is running, after all, on top of Oracle 8, something you can 't help noticing as 800M bytes of disk space disappears during installation. Still, Oracle 's GUI was clean.
With a minimum amount of excess baggage, Oracle presented the best interface for managing the server and its schema of any of the vendors.
Management is more than configuring and tweaking the server. Monitoring server reliability and performance is vital when large directories are in operation.
With iPlanet 's server, you can monitor server operations via SNMP, through the administrative Web server via the command line, or by peeking in the LDAP directory itself with an LDAP client or LDAP application.
The server of CA's eTrust Directory has a similar approach, but there is no administrative Web server to expose those statistics. These statistics are available both through SNMP and Common Management Information Protocol, the ISO-based management equivalent of the Internet 's SNMP.
Contrast these two products' monitoring utilities with those from Oracle's OID and Novell 's NDS eDirectory. The only way you know that your NDS eDirectory is getting hits is by watching the light on the disk drive. Novell says its next version of the product will offer some LDAP-based performance monitoring tools.
Oracle offers no LDAP-specific monitoring tools, either. Because the relationship between the database and the LDAP server is transparent, there is no way to turn Oracle statistics into LDAP statistics.
More middle-of-the-road monitoring tools come from Critical Path 's Global Directory Server and Siemens AG's DirX, both of which maintain information about directory performance in the X.500 directory. You can get at the data if you have to, but linking those directories with your existing network management station can be cumbersome.
LDAP doesn 't require much of a directory server in terms of back-end services.
Network managers, however, may have other requirements. For example, distributed enterprises may want servers to automatically distribute data; decentralized management models may need the directory to support complex security models; extranet-oriented organizations might want proxy and security services out of a directory server.
The directories we tested differ greatly in their support for some of these back-end features. While we did not test these features ourselves (because we only installed one instance of each directory in our test bed), we believe a look at what each vendor has to offer in these areas is warranted for this evaluation.
However, it 's not as simple as saying, "X.500 has a lot more features than LDAP." For example, iPlanet 's directory server has the capability of performing break-in detection and enforcing a password policy to encourage more secure passwords. At the same time, the operating system-oriented directory from Novell had its own strengths, particularly in distributing data and control across multiple servers.
In general, though, X.500 directories do have more back-end features. All the X.500-based directories had a full slate of replication tools, while iPlanet 's Directory Server was restricted to a master-slave replication scheme.
ETrust Directory was particularly strong in this area, offering replication not only between other X.500 directories, but also between X.500 and LDAP directories. It 's the only directory that fully bridges the gap in both directions between these two protocols. ETrust Directory also brought a high-speed/low overhead proprietary replication to the table, using the underlying database 's (OpenIngres) built-in replication tool. OID, because it is built upon Oracle 's core database engine, has a similar feature. Novell has long offered replication services between distributed directory services, as well.
Chaining and referrals are two other areas where the directories behave significantly different. A referral is used to provide useful information to a client when a directory doesn 't have the answer the client is looking for. For example, if a client asked an LDAP directory for thee-mail address of someone in the accounting department, the directory might not know the answer, but it might know where the LDAP server for the accounting department is located. In that case, the directory can return a referral to help the client find the information rather than saying, "I don 't know." All directories in this evaluation claim to support referrals.
The next step up from referrals is chaining. With chaining, one directory will query a different directory on behalf of the client. Rather than telling the client where to go, the directory can conduct the query and give the client an answer. Chaining is built into the X.500 world, but not the LDAP world. Only Innosoft 's IDDS supported chaining in the non-X.500 directory set we looked at. Chaining can be used to build a directory proxy. Innosoft offers an LDAP proxy with sophisticated access controls as a separate product. CA also built some proxy and relay features into its eTrust Directory.
Although the X.500-based directories have more back-end features than the LDAP-only directories, this shouldn 't sway your buying decision unless you specifically need one or more of those features.
Snyder is a senior partner at Opus One in Tuscon, Arizona, specializing in security and messaging technologies. He can be reached at firstname.lastname@example.org.
Snyder is also a member of the Network World Test Alliance, a cooperative of the premier reviewers in the network industry. For more Test Alliance information, including what it takes to become a member go to www.nwfusion.com/alliance.