|
LDAP: Fulfilling the Promise for Directory-Enabled Networks
March 1998
Executive Summary
Directory services play the important role of helping users locate resources on a network. The need for this function has grown
along with the size of the corporate network. What was only a nicety on LANs that connected tens or hundreds of clients has become a truly critical service on intranets that connect thousands of resources and often have
links to the Internet with its millions of resources and users. The need for directory services has evolved well beyond the simple friendly-name-to-email-address or DNS-name-to-IP-address conversion that used to
define directory services. Today, directory services are needed for the common white-pages information like email address, telephone number and fax number as well as for other per-user information such as browser
bookmarks, saved search-engine queries and email and document preferences. The need for directory services goes well beyond white-pages information. Policy-based networks (PBNs) and guaranteed Quality of Service
(QoS) applications are also driving the demand for directories. A variety of applications such as Web services, electronic messaging, groupware, process automation and collaborative computing use directory services for
everything from user authentication and authorization to centralized administration and management. Directory services allow diverse applications to share application preferences, to offer centralized management and to
support end-user location independence. Internet Electronic Commerce (EC) requires directory services that support yellow-pages searches. Router and switch vendors hope to store configuration information in the
directory. If the need is so dire, why have vendors not kept abreast of the needs, and provided solutions to the problems? Part of the reason is the lack of commercial acceptance of the existing international
standards for directory services, X.500. X.500 has been specified since 1988, but most vendors found the standards too complex and the market too small to justify implementing directory services within their products.
It was easier to provide proprietary, application-specific directories instead of providing an interface to a directory that few used and fewer understood. Over the past two years, however, the Lightweight Directory
Access Protocol (LDAP), has seen increasing support among vendors and users as both an alternative and an adjunct to directories based on the X.500 standard. LDAP is poised to do what X.500 failed to do—that is, provide
a directory services infrastructure that vendors are happy to implement and support in their products that can meet the immediate and mid-term directory needs of customers. LDAP is both a directory access protocol and
a stand-alone distributed directory service. Therefore, LDAP can be used to make legacy and proprietary directories available to LDAP clients or it can be used to create a complete directory service. LDAP has become the
glue that will allow applications to access information in many and diverse directories. LDAP has a number of capabilities and attributes that make it a very fitting solution to many of the directory problems. LDAP
retains the best parts of X.500 but is simpler and easier for customers to mange and vendors to write to. It offers true vendor independence, since it is “slim” enough that clients can be written even for computers with
only minimal processing power. LDAP also has a number of features that provide cost efficiencies and cost savings. For example, LDAP is implemented across platforms and operating systems, which lets organizations use
existing hardware for servers and doesn’t force the stranding of a platform due to a lack of an LDAP client implementation. The future of LDAP will include refinements that will help create a more scalable and
manageable distributed directory. These include plans for standardizing LDAP replication. There are a number of proposals for extensions to LDAP for features such as dynamic directory entries, which will be important
for good support of Internet phone, chat and video- and audio-conferencing. LDAP brings together the right mix of X.500’s functionality and the Internet Engineering Task Force's (IETF) penchant for simplicity. LDAP is
poised to become the most widely deployed directory protocol ever created. Its heritage lends itself perfectly to the tasks at hand. LDAP began as an access protocol for X.500 directories, yet has become capable of
supporting a complete, high-functionality directory service itself. Today LDAP is being called upon to do both of these things: It must act as an access protocol for many directories, both based on proprietary protocols
as well as standard protocols like X.500, and it is being used as a stand-alone directory services system. LDAP is likely to succeed because it provides the right mix of simplicity and power. It removes the
barriers that have kept many vendors from implementing standards-based directory services in their products and customers from adopting directories as a strategic part of their information systems architectures. Introduction
Directory services play the important role of helping users (and, increasingly, network applications and services) “find stuff” on a network. While it might sound trite, the need for
this function has grown along with the size of the corporate network. What was only a nicety on LANs that connected tens or hundreds of clients has become a truly critical service on intranets that connect thousands of
resources and often have links to the Internet with its millions of resources and users. For a long time, directory services were considered in the realm of electronic mail, as finding the email address for a person
was perhaps the most obvious application of a directory. The role of the directory has expanded over the last five years, however, to encompass many more functions than simply mapping a “friendly name” to an email
address. The reasons for this expansion are many, and include:
- The explosion of network connectivity
. Five years ago, the percentage of business computers connected to a network was only 23 percent; today analysts place that number at over 50 percent. The total number
of PCs connected to networks (both business and home) is estimated at 150 million in 1997 and expected to grow to 269 million by the year 2001. With so many machines able to access a network, it’s not surprising
that finding resources on the network is a problem.
- The need to consolidate directory data.
Organizations are looking for ways to reduce the number of directories they actively manage. Studies suggest that the average Fortune 1000 company has between 75 and
500 deployed directories. Getting from 500 to 400 or from 75 to 50 means dramatic cost savings, higher quality data and lower security hazards.
- Applications need directory data also.
An end user looking up a colleague’s email address is one example of a directory lookup. But increasingly, it is applications, not end users, that need to look for
information in a directory. For example, Web servers need to look up a user’s access control rights before serving that user a Web page. Messaging servers need to know where a user’s mailbox is located so they
can route email correctly. Web proxies and firewalls need to authenticate users before allowing them onto the public Internet.
- New network services
. When the Network Operating System (NOS) provided only file sharing and printing services, a directory helped people find file servers and printers. As new types of services and servers
appear on the network, and as networked applications become the norm rather than the exception, directory services take on the critical role of organizing resources so that users and applications can make use of
components of the network.
- Corporate intranets
. The transformation of corporate LANs into the corporate intranet has brought security concerns to the top of the list for many network administrators. When LANs largely isolated
workgroups from one another, security was a concern, but not a nightmare. Now that TCP/IP is on every desktop, access control has become mandatory. A directory is the logical place to store usernames, passwords,
certificates and public keys. It provides the framework for strong authentication and encryption technologies that are coming into wide use on intranets as well as on the Internet.
- Extranets
. The emerging business to business network (extranet) between customers, suppliers and business partners requires directory services for security as well as for a common repository for information
such as employee/contractor status, product specifications and pricing, inventory control and logistics. These directories must inter-operate across business boundaries and integrate with multiple corporate
information repositories. Many companies have built their extranet applications as LDAP clients, allowing them to share a common source of user, group and access control information. This sharing dramatically
lowers the cost of developing, deploying and supporting a new application. Where organizations may have deployed one or two applications every few years to their suppliers and partners, they may now be able to
deploy one to two applications per month, partly because they do not need to rebuild an authorization service for each application.
- Electronic commerce
. The expanding opportunity of electronic commerce (EC) has also helped create urgency around directory services. EC using the Internet requires a directory for two primary reasons. One is
to help users locate vendors. The second is that the directory plays a critical role in the public key infrastructure, which is necessary to secure transactions. Electronic commerce over the Internet demands
both encryption and digital signature technology so that transactions can be signed (making them resistant to tampering) and encrypted (making them private to the parties involved).
Why has it taken this long for vendors and users to recognize this nascent need for directory services? Well, it hasn’t. The needs have been growing steadily. And the problem was not
a lack of specified and agreed-upon directory services protocols. The X.500 suite of protocols has been updated three times since its original acceptance as an international standard in 1988. The problem was that most vendors found the standards too complex and the market too small to justify implementing directory services within their products. It was easier to provide proprietary, application-specific directories in their products instead of providing an interface to a directory that few used and fewer understood.
Over the past two years, however, the Lightweight Directory Access Protocol (LDAP), has seen increasing support among vendors and users as both an alternative and an adjunct to directories based on the X.500
standard. LDAP is poised to do what X.500 failed to do—that is, provide a directory services infrastructure that vendors are happy to implement and support in their products.
LDAP is the Glue for Multiple Information Systems
LDAP was originally developed as a lightweight access method for X.500 directories. Over time, it has grown to be capable of supporting a complete directory
service, but its roots are as a front-end to access X.500 directory servers. Vendors have recognized the value of standards-based directory access and just about every directory services vendor now supports, or plans to
support LDAP access to their directories. In this manner, LDAP has become the glue that will allow applications and users access to information in many and diverse directories. This is of enormous value to users and
application developers. It used to be necessary for users to use different tools to access different directories; most collaborative applications have some sort of directory built in and none of them can talk to one
another. Application developers needed to choose a directory system to support or, most often, they would just create a private directory usable only by their application to store users, configuration information,
passwords, etc. LDAP is changing all that. Now applications developers can use a standard protocol—LDAP—to access a capable directory in a standard manner. They can store information about their application,
information about who can access it, and even configuration information in the directory. It saves time and money by freeing users from separate passwords for each application, from being forced to use different tools
to look up users in different applications and from having their personal configuration information tied to the computer on their desk. This last point is important, since often configuration information was stored
locally on a computer; a user’s environment depended on the computer they were using. When such information is stored in a central place, accessible from any machine on the network, a user’s environment is not tied to
the computer at which they are sitting. But LDAP goes beyond simplifying applications developers’ and users’ lives—it has begun to deliver on the promise of directory-enabled networking.
Directory Services: More Than Your Address Book
For a long time, directory services were relegated to the realm of the applications programmer. The OSI X.500 directory is defined as application layer protocols.
Directories were seen only as a means of mapping names to addresses. Thus, directories were largely left to the electronic mail people to worry about. They were the only group that was vocal about the need and promise
of directory-enabled networking. At the user level, directory services can fill obvious needs, such as finding the phone number, fax number or email address for an individual. This type of access is often called
white-pages access, since the directory is used like the white pages of the telephone directory. But there are many more useful applications of directory services for users. Some products, such as email switches,
use the directory to store attributes such as a user’s preferred document formats, public cryptographic keys and email distribution lists, filtering and forwarding instructions. Other information, such as Web browser
bookmarks and frequently used Web searches are also candidates for storage in a directory. Again, the advantage to storing such information in the directory is that it becomes accessible to the user from any machine in
the network, not just from their desktop. Beyond White-Pages Information
The directory was thus seen primarily as a means for applications to share information about users and other applications.
But the directory is suited to much more than simply user information. Once the directory expands beyond user lookup to application and device lookup, it can serve multiple purposes and become a common network resource
and its value increase geometrically. Today, organizations are beginning to make use of these expanded directory capabilities and are beginning to plan directory infrastructures for a common logical directory service
that services multiple applications. For example, special programs on the Internet have been carrying out basic directory functions (mapping names to addresses and vice versa) for more than 10 years. The Domain Name
System (DNS) provides these directory services on the Internet. It maps domain names to IP addresses (and vice versa) and it provides email routing information for domain names. There were X.500 pilots on the Internet,
but they concentrated on the user level directory services, rather than on replacing or enhancing the functions of the DNS. Many still resist migrating away from the current Domain Name System implementation (primarily
based on Unix BIND), since it has proved both reliable and scalable. Security is another obvious use for the directory. The directory became the logical place for usernames and passwords as well as public-key data
such as certificates and key material. Directory services are the primary enabler for single login, which requires a user to authenticate only once to the directory. All other servers and applications use access
control information from the directory to allow or disallow services for that user, without requiring that the user authenticate to each application. Directory services can also centrally manage password policies such
as how long a password must be, whether users can reuse passwords, and so on. Another use for the directory is yellow-pages
functions. Yellow-pages searches generally find all entries in the directory whose attributes satisfy some search criteria. For example, an electronic commerce application might want to search for all companies that manufacture digital audio components. A Web application might want to search for all users with signing authority above $5,000 in department 3320. Yellow-pages capabilities are especially needed for Internet electronic commerce, as potential customers need a way to find all vendors of a given part, for example. Companies deploying these types of applications must select their directory with care. Some directory services are more scalable than others are, and organizations must accurately gauge their application requirements to select a directory that is capable of handling their anticipated load.
Another yellow-pages issue is the eventual adoption of Uniform Resource Names (URNs) on the Internet. URNs will have greater persistence than today's URLs do. So, even if the resource moves from server to server and
the URL changes, the URN would remain constant. Currently, to find a document or resource on a specific topic, your best bet is to visit a search engine site on the Web and query their database of Internet resources. As
URNs are adopted, it makes sense to store them (and other metadata about the resource) in the directory. Lastly, users and administrators now see that directory services might be the proper place for other
functions common in an enterprise network. Some wonder why, for example, routers could not authenticate to a directory and request to download their configuration information directly from the directory. The advantages
to such a scheme are many. It places a level of indirection between the machines and their configurations. So a router could obtain its identity (and configuration) from the directory instead of having it hard-coded
into the box. To replace a router, it could be swapped in and booted and it would immediately assume the role of the device that it replaces. In another example, if the router has access to user profiles, it can
guarantee fixed bandwidth or latency, providing a predetermined QoS determined by the individual, not some IP address. This same scenario holds for many, many other network devices, such as remote access units, modem
pools, etc. The figure below illustrates the potential directory applications at various network layers: Thus, the prevailing view of the directory has changed from one in which the
directory is primarily used by users and applications for name-to-address translation to one in which the directory holds all information about an entity. The entity may be
a user, a device, an application or a service. The information may be for use by the entity itself or any other user or program that needs access to the information. The directory will enable a whole new class of network functionality. Policy-based
networks (PBNs) let network managers give certain applications or certain users the highest class of service while less critical applications and users get a lower class
of service. Companies are using PBN technology to let organizations optimize existing bandwidth rather than having to install “bigger pipes” to achieve desired
network application performance. Directories are a critical piece of PBNs, since the directory stores the policies and makes them available to devices such as hubs,
routers and switches throughout the network. The use of Quality of Service (QoS) in PBNs requires end-to-end support, however. All devices—routers, edge devices
(boundary switches and remote access devices), and network interface cards on user machines and servers—must support QoS control. While the usual directory services scenario revolves around doing searches on
relatively static information such as names, email addresses and phone numbers, there is growing interest by some people in storing more dynamic information in the
directory. Dynamic directory services store information that only persists in its accuracy and value when it is being periodically refreshed. This information can be
stored as dynamic entries in the directory. A typical use might be a person or application that is either online—in which case it has an entry in the directory—or is
offline, in which case its entry disappears from the directory. Dynamic directory services will be important for a number of purposes, and will be critical for services
such as Internet telephony, chat and computer conferencing, for example, to store whether a user is online and available to accept connections. How Do Current Solutions Measure Up?
Today, directory services solutions fall into four general categories: completely proprietary systems; “pure” standards-based systems built on X.500 or LDAP;
hybrid systems consisting of proprietary directories that support standards-based access; and meta-directories. We won’t explore the completely proprietary case. Many of the systems that fall
into this category are either being phased out in favor of a directory that fits in another category (such as the migration from Microsoft’s Windows NT Directory to
Active Directory) or their vendors are adding standards-based interfaces, moving these products into the hybrid category. “Pure” standards-based systems, such as those available from Control Data
Systems (X.500) and Netscape Communications (LDAP) offer all the benefits of standards-based products. The level of interoperability among products is usually
excellent. The products themselves are generally strong. The biggest problem with standards-based solutions is that sometimes the standards process itself stifles
vendors’ ability to deliver solutions to customer problems. For example, LDAP replication is a customer requirement for many organizations, yet there are still no
IETF standards for LDAP replication, so there are no “pure” standards-based products that support the feature. As a result, suppliers fill the gap until the standards catch up.
Hybrid systems abound. For example, Novell NDS and Microsoft Active Directory are not X.500 implementations. However, both are proprietary directories that
implement some standards-based interfaces. Both NDS and Active Directory use X.500/LDAP naming conventions, for example, and both support LDAP clients.
Some vendors imply that hybrid systems offer the “best of both worlds,” by using proprietary core technology for speed and extensibility, yet still offering clients
access to the services using standards-based interfaces. We believe, however, that the hybrid approach suffers from many of the same problems as the
meta-directories. Namely, the conversion and mapping that must be done to convert entries between the standards-based form and the internal, proprietary form are often not lossless transformations.
Finally, there are the meta-directories. Meta-directories are often used to tie together products that provide proprietary directory services. Most meta-directory
products are nothing more than a full-featured directory with extensive directory synchronization tools. They promise to provide synchronization among multiple
directories as well as provide a consistent interface to users and application developers. While this path may seem a prudent one, in practice, we have seen many problems arise.
The problems often stem from the fact that meta-directories are usually just directory synchronization engines that map directory attributes between proprietary
directories and a canonical directory format. Unfortunately, mapping directory attributes and schemas is a tricky undertaking. The translations are often
unidirectional, and are quite often “lossy.” That is, some attributes may not map from schema to schema and may be lost in the conversion. However,
meta-directories can be indispensable when you need to tie together a number of legacy products that do not (and will not) support any standards-based directory access to their proprietary directories.
How Does LDAP Solve the Problems?
The Internet and World Wide Web have changed the face of computing over the past five years. The Internet and Web have sparked the widespread acceptance of
computing and accelerated the number of computers connected to a network. According to Dataquest research, of the 220 million people over the age of 16 in the
US and Canada, 23 percent or 50.6 million use the Internet. As the number of computers connected to networks and the Internet increases, the need for directory services skyrockets.
As intranets replace LANs in companies, services based on standards like LDAP help companies level the playing field. Protocols like SMTP, POP3, IMAP, SNMP
and LDAP are being adopted by corporations for a reason. It’s not because they are the only choice—they are not. It is because standards make life easier for users
and administrators, demonstrably reduce costs and contribute to the development of a standard infrastructure that delivers multiple applications quickly and allows rapid transition as technology and market needs change.
Standards let administrators concentrate on building services rather than worrying about how to integrate software products from various vendors into a cohesive and
useful service. Standards make it possible for the corner grocery store to order products from my company, even though they use a Macintosh and I have a network of Unix computers.
LDAP is a standard protocol. With it you can implement an intranet or global directory service. As opposed to X.500, however, LDAP is not a database standard.
LDAP defines an access protocol, an API and a common file format. For this reason, software developers can easily develop applications that take advantage of
its services. It is flexible: You can create a directory service using only LDAP, or you can use LDAP to inter-operate with an X.500 directory service. As vendors
provide LDAP front ends for proprietary systems, any user with an LDAP client can access those systems. LDAP delivers interoperability and reduces a company’s
dependency on any single vendor when they can choose implementations based on the standard technology. LDAP is a living protocol. People using it to solve existing problems are working to
extend and enhance LDAP so that it can provide a directory service that can do all of the things we talked about in the previous section. Since the standardization of
LDAPv3 as RFCs 2251-2256, two new working groups have emerged to standardize LDAPv3 extensions (such as type-down addressing), access controls and replication.
Vendors such as Bay Networks are looking to LDAP to let them develop “policy-enabled networking” solutions that grant access to network resources
according to information stored in the directory (such as user information, group membership or rules specifying arbitrarily complex criteria based on other directory
attributes). Bay is also looking at using LDAP directories to store configuration information for routers and switches. Other vendors also involved in policy-based networking, such as 3Com and New
Oak Communications, let organizations optimize existing bandwidth rather than having to install “bigger pipes” to achieve desired network application performance.
LDAP directories play a role in both companies plans, as a repository for the policies. LDAP is central to many vendors’ plans to offer quality of service guarantees to
users based on attributes in the directory. Companies such as CLASS Data Systems let network managers devise policies that guarantee certain users or applications a set bandwidth over network connections.
Industry Initiatives
There have been several industry initiatives to help meet the growing customer and vendor demand for standard directory services.
Back in April of 1996, Netscape Communications recognized the importance of standards-based directory services to the network computing community and they
rallied support around the LDAP protocol. They brought together 40 companies, including IBM/Lotus, SunSoft, Digital Equipment Corporation and VeriSign, to
support LDAP as a standard for accessing X.500 and LDAP directories. This effort drew attention to LDAP and the announcement caused many other vendors to
reevaluate the direction that they were taking regarding directory services. There are also a number of initiatives underway to define a standard set of attributes
so that LDAP implementations will be able to inter-operate and all directories will have the same schema. Individual companies will be able to extend the schema, but
a core set of attributes will allow queries between organizations. Today there is no standardization, and thus each organization has been left to develop its own
schema or use publicly available models such as X.500. The IETF recently created a new working group called Schema Registration to act as a clearinghouse for
LDAP schema. This public form will help vendors ship products that use publicly published schema. The Directory Enabled Networking initiative is committed to publishing its schema in
the relevant standards bodies (IETF and DMTF). In May of 1997, Cisco and Microsoft announced that Cisco had licensed Microsoft’s Active Directory and that Cisco would implement Active Directory on a number of
Unix platforms. According to Microsoft, Active Directory provides LDAP directory services. Cisco and Microsoft will jointly extend and enhance Active Directory to
support network service modeling, provisioning and administration, and would add user-based policies. Cisco will integrate Active Directory with their Internetwork
Operating System (IOS) software, which runs on Cisco’s line of routers, switches and servers. The stated goal of the agreement is to provide a single directory
infrastructure for operating systems and network services. Currently, Netscape’s Directory Server is the only major directory services product that runs on both Unix and Microsoft NT.
Why LDAP Will Succeed Where Others Have Failed
Why is it that we see LDAP as a survivor when other standards-based directory protocols, such as X.500, have failed to fill the needs and spark the imagination of
the industry? There are several reasons:
- LDAP takes the best features of X.500 and does away with the complexity and Open Systems Interconnect (OSI) baggage that full X.500 brings with it.
- LDAP was designed from the ground up as an Internet protocol, utilizing TCP/IP for its transport.
- LDAP is both an access protocol as well as a flexible directory system.
- LDAP implementations are relatively low-cost, easy-to-deploy and easy-to-manage.
- The best LDAP implements offer performance that meets the needs of applications that depend on them. Early performance tests (such as those
conducted by Mindcraft, http://www.mindcraft.com/perfreports/ldap/) indicate that LDAP implementations provide significantly lower response times than their X.500 and proprietary counterparts.
LDAP Takes the Best Features of X.500 and Builds Upon Them
X.500 is a set of standards that defines a directory service built upon OSI protocols.
X.500 describes both an information model and a set of protocols for querying, replicating and manipulating directory information. X.500 directories are full featured,
but they are also extremely complicated for vendors to write and organizations to deploy. Perhaps the most important aspect of X.500 is that it defines a global directory structure.
LDAP, like X.500, is both an information model and a protocol for querying and manipulating directory information. LDAP also has a standard C API (RFC 1823)
that is being updated to accommodate the changes in LDAPv3 as well as Java. LDAP’s namespace and data model is essentially the same as that of X.500. The LDAP information model is based on entries, referred to by their
distinguished names, which are simply collections of attributes and values. X.500 and LDAP have much in common:
- A hierarchical directory organization with a hierarchical namespace.
- Object-oriented directories: Both LDAP and X.500 represent directory objects as entries; both use an object class attribute to specify the object type of an entry (for example, person, organization or computer).
- Name components (Common Name, Country, etc.) are typed. This approach differs from that adopted by some other directories, which use typeless names, such as domain names in the DNS.
- Both X.500 and LDAP share attribute type definitions.
Like LDAP, X.500 is based on standards and can describe any object. Unlike LDAP, X.500 is much more complex, both for vendors to implement and for user
organizations to deploy. But LDAP retains the ability to perform powerful searches on the directory. Like X.500, LDAP directories allow for a distributed directory service that can be spread across multiple servers. LDAP and X.500 servers can inter-operate, with LDAP servers passing queries to X.500 servers or Directory Services Agents (DSAs) and returning results to LDAP clients.
LDAP Was Designed as an Internet Protocol
Where LDAP differs from X.500 is that it is designed to run directly over TCP/IP. By replacing OSI protocols with the simpler TCP/IP protocols and forgoing some of the
lesser-used features of X.500’s Directory Access Protocol (DAP), LDAP clients and servers are “thinner” than X.500. That is, they are easier to implement, perform
better and can be run on smaller platforms than X.500 clients and servers. LDAP, like most Internet protocols, uses a simple, string-based data encoding for
representing directory entries. X.500, on the other hand, uses a highly structured encoding that requires considerable processing power just to encode and decode.
LDAP is Both an Access Protocol and a Flexible Directory Service
Originally, LDAP was intended only as a lightweight access protocol for X.500
directories – that is, only as a means for TCP/IP clients to query an X.500 directory service. As LDAP was deployed, the developers wanted to allow LDAP servers to
support stand-alone, distributed directory services without using X.500. LDAP version 2 introduced this capability, which let organizations use LDAP directory
servers as a stand-alone directory service. LDAPv2 allowed multiple servers to form a distributed directory service, but using a master-slave model which is much simpler than the distributed topology supported by X.500.
So, LDAP can be used both to front-end legacy and proprietary directories, integrating them into either an X.500 directory system or one based solely on LDAP.
It’s precisely this feature that has helped catapult LDAP onto every vendor’s list of features. For example, Microsoft can and will provide an LDAP front-end for the
Active Directory, which will be available with Windows NT 5.0. Any LDAP client will then be able to query the information in the directory.
The work on the LDAP version 3 specification is largely finished. LDAPv3 includes the following major new features: Referrals – LDAPv3 supports referrals. When an LDAP server does not have
information to answer a query, it can refer the client to another server that may be able to answer the query. Security – LDAPv3 adds support for strong authentication via X.509 certificates.
LDAPv3 servers will be able to store public keys using X.509v3. LDAPv3 also supports the use of Secure Sockets Layer (SSL) between clients and servers, which encrypts the session between client and server.
Support for Unicode characters – LDAPv3 supports the UTF-8 encoding of Unicode, allowing a greater range of multilingual character sets to be encoded in directory attributes. Extensibility
– LDAPv3 allows new operations to be added without changes to the core protocol through the use of LDAP “controls.” The most important work still underway has to do with replication protocols. Until
more flexible means exist for directory information to be replicated across administrative domains (such as between companies), a global directory will not be
feasible using only standard LDAP servers. But there are proposed protocols before the IETF for both multi-master and single-master directory replication schemes.
Key LDAP Attributes That Provide Cost Efficiencies and Savings
There are a number of features of LDAP that make it attractive to organizations
looking for a directory solution. Because it is an Internet standard, it supports multi-vendor interoperability in the same manner as TCP/IP, SMTP and SNMP.
Internet standards assume cross-platform support. Implementations of LDAP clients and servers are (or will be) available to run on any number of processor architectures
and on any number of operating systems. By giving customers the ability to run products on platforms that they already have and already know how to support, standards-based software saves companies time and money.
The fact that LDAP is an Internet standard also makes it attractive to the developer community. Because it is an Internet standard, there are implementations available
that give developers a starting point and reference platform against which to test and/or judge their work. LDAP is widely implemented across platforms and operating systems. There are
two reasons for this. One is that LDAP is based on TCP/IP. The other is that LDAP is a simple protocol to understand and implement (relative to X.500). Both of these
reasons are important to the widespread adoption of LDAP by third parties. Native or “pure” LDAP implementations can provide savings over the meta-directory
or directory synchronization approaches. The meta-directory approach usually relies on directory synchronization at some level. Directory synchronization often involves
mappings and translations that are “lossy.” Directory synchronization may also require significantly more administrative time than simple directory management.
Native LDAP directories may offer advantages because of easier administration and a single point of administration. LDAP uses TCP as its network transport protocol. TCP takes care of all of the
problems associated with sequencing and ordering of packets and provides a byte-stream session between LDAP client and server or between LDAP servers.
LDAP is truly a lightweight protocol when compared to X.500’s DAP, from which LDAP was initially derived. LDAP’s use of Internet protocols for transport makes it
easier to implement for vendors and widely accessible for organizations, the majority of which now run TCP/IP directly to most of their desktop machines.
Finally, LDAPv3 provides a means for vendors and others to add new operations to LDAP without breaking the core protocol. This mechanism will help vendors provide
enhancements that can be implemented by others as they see fit without compromising core interoperability. Where Will It Go From Here?
The evolution of LDAP through the current version has seen the protocol move from a lightweight protocol to one that some might call middleweight. While LDAPv3 has
addressed the most serious shortcomings of the older versions of LDAP, there is still work that has to be done to assure LDAP’s utility and scalability into the future.
Perhaps the most important effort is to standardize LDAP replication protocols. This is an important step that is likely to come to agreement this year.
Server-to-server security also still needs the attention of the IETF so that an accepted method for encrypting server-to-server communications can be arrived at.
Work on extensions and enhancements to LDAP will continue at the rapid pace evident throughout 1997. The proposed extensions for LDAPv3 already include:
- Access control and authentication
- Sorting and paged retrieval of search results
- Dynamic directories
- Schema, referral and knowledge reference maintenance
- LDAP server discovery
- LDAP APIs
Conclusions
LDAP brings together the right mix of X.500’s functionality and the IETF’s penchant for simplicity. LDAP is poised to become the most widely deployed directory
protocol ever created. Its heritage lends itself perfectly to the tasks at hand. LDAP began as an access protocol for X.500 directories, yet has become capable of
supporting a complete, high-functionality directory service itself. Today LDAP is being called upon to do both of those things. It must act as an access protocol for
many directories, both based on proprietary protocols as well as standard protocols like X.500 and it is being used as a stand-alone directory services system.
From its beginning, LDAP was designed as a protocol to run over TCP/IP and the Internet. That is particularly important, as intranets have largely displaced LANs
based on proprietary protocols in most organizations. It also means that you won’t strand users of any single platform by rolling out an LDAP directory. Clients and
servers are or will be available for most popular machine architectures and operating systems. An LDAP directory can serve your Macintosh clients as well as your Windows, NT and Unix clients.
LDAP is likely to succeed because it provides the right mix of simplicity and power. It removes the barriers that have kept many vendors from implementing
standards-based directory services in their products and customers from adopting directories as a strategic part of their information systems architectures. It provides
a directory service that is both scalable and extensible. This is very important, since any directory service that sees widespread implementation will quickly be called
upon for experimentation and duties not foreseen by LDAP’s developers. In summary, LDAP has the potential to satisfy the current directory needs (making
legacy directory information available to intranet clients, providing a standard API and set of services for use by applications programmers, and providing an
extensible, scalable directory service) as well as become the basis for future work. Recommendations for Customers
- Let your business requirements drive your directory strategy, deploying useful applications that will deliver rapid return on investment while simultaneously providing proof of concept.
- Evaluate, pilot and deploy LDAP directory services incrementally. Deploy LDAP solutions within an overarching directory service strategy.
- Demand that vendors provide off-the-shelf LDAP solutions. Be skeptical of products that come with a proprietary directory; this can add cost and
administrative overhead. If an application manages users or groups, it should be an LDAP client rather than implementing its own directory.
- Performance is important. Make sure the directory you are evaluating supports the applications you plan to plug into it.
|
|
