LDAP
LDAP is a directory service based on the X.500 Directory
Services model that performs operations management functions, acting as a
storehouse of information for applications and as a central part of modern OS
services. LDAP is both an information repository and a protocol for querying and
manipulating the data in a directory. LDAP binds together system information
(distributed across multiple computers) with system services and client
applications to make it simpler to access user preferences, application
configuration data, and security configuration data, and to locate services on
the local network.
LDAP is not designed to hold many hundreds of thousands of entries
as are traditional databases. LDAP can be thought of as a hierarchically organized lightweight database. It was designed to
contain small records of information in a hierarchical structure. The individual
nodes contain attributes and connect to other subtrees, so the structure appears
much like the directory of a file system. It is important to remember that LDAP
uses very small databases to enable fast access, and it cannot be used as if it
were a large commercial database such as Oracle, Sybase, DB/2, or SQL Server.
There are currently only a handful of native LDAP servers, including the
following:
-
IBM's DS Series LDAP Directory (AIX) [16]
-
Innosoft's Distributed Directory Server (Linux) [17]
-
Netscape Directory Server (Linux) [18]
-
OpenLDAP server (Linux) [19]
-
Sun Microsystems' Directory Services (Solaris) [20]
-
University of Michigan's SLAPD [21]
Although Microsoft's Active Directory also uses LDAP natively, it
also extends the protocol. Other directory service systems also support LDAP
queries, primarily through the use of proprietary APIs with interfaces for LDAP
communications. Some of these include Novell's eDirectory, Microsoft's Active
Directory, and Lotus Domino.
Native LDAP clients interact with the directory server for
authentication and authorization. Clients authenticate to an LDAP server by
attempting a bind operation. A connection is established between the client and
server if the bind is successful. The client chooses which authentication method
it wants to use and supplies the credentials required by that method during the
bind process. The client is bound as an anonymous user, and the credentials are
sent if an authentication is not specified. LDAP authorization to directory
objects is based on an Access Control List (ACL).
LDAP is used as an application server to retrieve information from
a directory such as a list of personnel contact information. LDAP is also used
by different applications to retrieve the information they require. A user's
query can be matched against an LDAP server through the use of a search engine,
pointing to the place where the actual data are located. A DNS server can also
structure its records internally in an LDAP hierarchy. LDAP can also be used by
one application to exchange data with another or as a gateway between two
incompatible applications as an interapplication data exchange interface.
LDAP is used by an operating system to communicate information
between its different resources or components. The LDAP service can host
information about user accounts and preferences for a group of machines. The
LDAP server can contain the access rights of user accounts that are referenced
by the login system, the file system, and the application execution environment.
For example, during user login authentication, the login authentication service
on each system is directed to query the LDAP server each time a user attempts to
log in. The authentication service checks the results of the query to validate
the user. If the user is authorized, it then locates and loads his or her home
directory and other personal preferences.
LDAP provides a handful of common APIs to provide services such as
user authentication, network host information, network file system locators, and
other common network database applications. LDAP provides a basic service for
locating information and can be used to store information for other system
services, such as RADIUS and Kerberos.
LDAP communications consist of two elements: client-to-server
communications and server-to-server communications. Client-to-server
communications allow user applications to contact an LDAP server to create,
retrieve, modify, and delete data with the standard LDAP commands. The basic
command set of LDAP is enough to provide all that client applications should
need. The extended command operation in LDAP version 3 provides the capability
to add more operations; some vendors may take advantage of LDAP version 3 to
create proprietary extended operations to support their product line.
Server-to-server communications define how multiple servers on a network share
the contents of an LDAP directory information tree and how they update and
replicate information between themselves.
The basic LDAP architecture is a simple hierarchical structure of
information. At the root node, it provides a hierarchical view of all its data
and provides the capability to search the system for this data. The type of data
stored can vary depending on how you are using the LDAP server. You may have a
set of LDAP servers focused solely on servicing login information requests for
the users who are being supported, or you may have a server that contains host
address information used by the DNS and DHCP servers. If you do not have a large
network, this information could be combined into a single hierarchy, which is
called the Directory Information Tree (DIT). Subtrees of the DIT contain all of
the information contained on that LDAP server. Each node in the tree is called a
Directory Service Entry (DSE). These entries contain the actual records that
describe different real and abstract objects in the network infrastructure, such
as users, preferences, and devices. Each entry contains a set of properties, or
attributes, in which data values are stored.
If the real contents already exist somewhere in the directory, then entries can
be aliased. A special entry called the root DSE contains a description of the
whole tree, its layout, and its contents. This isn't the root of the tree itself
because the root node is virtual and doesn't really exist, so it can't be
directly accessed.
Enterprise Wireless Gateways (EWGs) are an example of many of
today's WLAN devices that have native LDAP client software. Because many of
today's WLAN infrastructures use LDAP for user-based authentication, it is
essential to understand the LDAP directory and how a client device and LDAP
client software would interface. RADIUS is commonly used for user authentication
in LDAP with wireless infrastructures. To ensure scalability, most RADIUS
software packages have support for interfacing with LDAP-compliant or
LDAP-compatible directories. This allows a RADIUS server to query a local LDAP
database directly for user authentication. This avoids the requirement of
manually entering all users into two databases—a savings of time and money.
Similarly, Kerberos services can be integrated with the Active Directory (or
LDAP-compatible) user database, making it more seamless and easier to manage
than disparate platforms and services.
Sections
Archive
Syndication
