1999-10-01 00:57:45 +08:00
|
|
|
# $OpenLDAP$
|
2007-01-03 04:00:42 +08:00
|
|
|
# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
|
1999-04-24 07:41:45 +08:00
|
|
|
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
2000-08-11 06:31:41 +08:00
|
|
|
H1: Introduction to OpenLDAP Directory Services
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2006-12-08 05:50:15 +08:00
|
|
|
This document describes how to build, configure, and operate
|
|
|
|
{{PRD:OpenLDAP}} Software to provide directory services. This
|
2006-12-08 13:02:21 +08:00
|
|
|
includes details on how to configure and run the Standalone
|
|
|
|
{{TERM:LDAP}} Daemon, {{slapd}}(8). It is intended for new and
|
2006-12-08 05:50:15 +08:00
|
|
|
experienced administrators alike. This section provides a basic
|
|
|
|
introduction to directory services and, in particular, the directory
|
|
|
|
services provided by {{slapd}}(8). This introduction is only
|
|
|
|
intended to provide enough information so one might get started
|
|
|
|
learning about {{TERM:LDAP}}, {{TERM:X.500}}, and directory services.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H2: What is a directory service?
|
|
|
|
|
2006-11-16 03:20:18 +08:00
|
|
|
A directory is a specialized database specifically designed for
|
|
|
|
searching and browsing, in additional to supporting basic lookup
|
|
|
|
and update functions.
|
|
|
|
|
|
|
|
Note: A directory is defined by some as merely a database optimized
|
|
|
|
for read access. This definition, at best, is overly simplistic.
|
|
|
|
|
|
|
|
Directories tend to contain descriptive, attribute-based information
|
|
|
|
and support sophisticated filtering capabilities. Directories
|
|
|
|
generally do not support complicated transaction or roll-back schemes
|
|
|
|
found in database management systems designed for handling high-volume
|
|
|
|
complex updates. Directory updates are typically simple all-or-nothing
|
|
|
|
changes, if they are allowed at all. Directories are generally
|
|
|
|
tuned to give quick response to high-volume lookup or search
|
|
|
|
operations. They may have the ability to replicate information
|
|
|
|
widely in order to increase availability and reliability, while
|
|
|
|
reducing response time. When directory information is replicated,
|
|
|
|
temporary inconsistencies between the replicas may be okay, as long
|
|
|
|
as inconsistencies are resolved in a timely manner.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
There are many different ways to provide a directory service.
|
|
|
|
Different methods allow different kinds of information to be stored
|
|
|
|
in the directory, place different requirements on how that information
|
|
|
|
can be referenced, queried and updated, how it is protected from
|
|
|
|
unauthorized access, etc. Some directory services are {{local}},
|
|
|
|
providing service to a restricted context (e.g., the finger service
|
|
|
|
on a single machine). Other services are global, providing service
|
|
|
|
to a much broader context (e.g., the entire Internet). Global
|
|
|
|
services are usually {{distributed}}, meaning that the data they
|
|
|
|
contain is spread across many machines, all of which cooperate to
|
|
|
|
provide the directory service. Typically a global service defines
|
|
|
|
a uniform {{namespace}} which gives the same view of the data no
|
2006-11-16 03:20:18 +08:00
|
|
|
matter where you are in relation to the data itself.
|
|
|
|
|
2006-12-08 05:50:15 +08:00
|
|
|
A web directory, such as provided by the {{Open Directory Project}}
|
2006-11-16 03:20:18 +08:00
|
|
|
<{{URL:http://dmoz.org}}>, is a good example of a directory service.
|
|
|
|
These services catalog web pages and are specifically designed to
|
|
|
|
support browsing and searching.
|
|
|
|
|
|
|
|
While some consider the Internet {{TERM[expand]DNS}} (DNS) is an
|
|
|
|
example of a globally distributed directory service, DNS is not
|
2007-08-07 00:08:05 +08:00
|
|
|
browseable nor searchable. It is more properly described as a
|
|
|
|
globally distributed {{lookup}} service.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
H2: What is LDAP?
|
|
|
|
|
2001-05-12 14:15:42 +08:00
|
|
|
{{TERM:LDAP}} stands for {{TERM[expand]LDAP}}. As the name suggests,
|
|
|
|
it is a lightweight protocol for accessing directory services,
|
|
|
|
specifically {{TERM:X.500}}-based directory services. LDAP runs
|
|
|
|
over {{TERM:TCP}}/{{TERM:IP}} or other connection oriented transfer
|
2006-06-10 01:20:38 +08:00
|
|
|
services. LDAP is an {{ORG:IETF}} Standard Track protocol and is
|
2006-12-10 00:53:09 +08:00
|
|
|
specified in "Lightweight Directory Access Protocol (LDAP) Technical
|
|
|
|
Specification Road Map" {{REF:RFC4510}}.
|
2006-06-10 01:20:38 +08:00
|
|
|
|
2006-12-08 05:50:15 +08:00
|
|
|
This section gives an overview of LDAP from a user's perspective.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2001-05-12 14:15:42 +08:00
|
|
|
{{What kind of information can be stored in the directory?}} The
|
|
|
|
LDAP information model is based on {{entries}}. An entry is a
|
|
|
|
collection of attributes that has a globally-unique {{TERM[expand]DN}}
|
|
|
|
(DN). The DN is used to refer to the entry unambiguously. Each of
|
|
|
|
the entry's attributes has a {{type}} and one or more {{values}}.
|
|
|
|
The types are typically mnemonic strings, like "{{EX:cn}}" for
|
|
|
|
common name, or "{{EX:mail}}" for email address. The syntax of
|
2002-06-15 09:00:50 +08:00
|
|
|
values depend on the attribute type. For example, a {{EX:cn}}
|
|
|
|
attribute might contain the value {{EX:Babs Jensen}}. A {{EX:mail}}
|
2001-05-12 14:15:42 +08:00
|
|
|
attribute might contain the value "{{EX:babs@example.com}}". A
|
2006-12-10 00:53:09 +08:00
|
|
|
{{EX:jpegPhoto}} attribute would contain a photograph in the
|
|
|
|
{{TERM:JPEG}} (binary) format.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
{{How is the information arranged?}} In LDAP, directory entries
|
|
|
|
are arranged in a hierarchical tree-like structure. Traditionally,
|
|
|
|
this structure reflected the geographic and/or organizational
|
2002-06-15 09:00:50 +08:00
|
|
|
boundaries. Entries representing countries appear at the top of
|
2001-05-12 14:15:42 +08:00
|
|
|
the tree. Below them are entries representing states and national
|
|
|
|
organizations. Below them might be entries representing organizational
|
|
|
|
units, people, printers, documents, or just about anything else
|
|
|
|
you can think of. Figure 1.1 shows an example LDAP directory tree
|
|
|
|
using traditional naming.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2007-08-01 19:30:50 +08:00
|
|
|
!import "intro_tree.png"; align="center"; \
|
2000-07-23 15:35:40 +08:00
|
|
|
title="LDAP directory tree (traditional naming)"
|
2000-07-23 08:20:04 +08:00
|
|
|
FT[align="Center"] Figure 1.1: LDAP directory tree (traditional naming)
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2001-05-12 14:15:42 +08:00
|
|
|
The tree may also be arranged based upon Internet domain names.
|
|
|
|
This naming approach is becoming increasing popular as it allows
|
2002-06-15 09:00:50 +08:00
|
|
|
for directory services to be located using the {{DNS}}.
|
2000-08-31 13:52:55 +08:00
|
|
|
Figure 1.2 shows an example LDAP directory tree using domain-based
|
|
|
|
naming.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2007-08-01 19:30:50 +08:00
|
|
|
!import "intro_dctree.png"; align="center"; \
|
2000-07-23 15:35:40 +08:00
|
|
|
title="LDAP directory tree (Internet naming)"
|
2000-07-23 08:20:04 +08:00
|
|
|
FT[align="Center"] Figure 1.2: LDAP directory tree (Internet naming)
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2000-07-23 08:20:04 +08:00
|
|
|
In addition, LDAP allows you to control which attributes are required
|
2001-05-12 14:15:42 +08:00
|
|
|
and allowed in an entry through the use of a special attribute
|
|
|
|
called {{EX:objectClass}}. The values of the {{EX:objectClass}}
|
|
|
|
attribute determine the {{schema}} rules the entry must obey.
|
|
|
|
|
|
|
|
{{How is the information referenced?}} An entry is referenced by
|
|
|
|
its distinguished name, which is constructed by taking the name of
|
|
|
|
the entry itself (called the {{TERM[expand]RDN}} or RDN) and
|
|
|
|
concatenating the names of its ancestor entries. For example, the
|
|
|
|
entry for Barbara Jensen in the Internet naming example above has
|
|
|
|
an RDN of {{EX:uid=babs}} and a DN of
|
2006-12-08 05:50:15 +08:00
|
|
|
{{EX:uid=babs,ou=People,dc=example,dc=com}}. The full DN format is
|
|
|
|
described in {{REF:RFC4514}}, "LDAP: String Representation of
|
2006-06-10 01:20:38 +08:00
|
|
|
Distinguished Names."
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
{{How is the information accessed?}} LDAP defines operations for
|
|
|
|
interrogating and updating the directory. Operations are provided
|
|
|
|
for adding and deleting an entry from the directory, changing an
|
|
|
|
existing entry, and changing the name of an entry. Most of the
|
|
|
|
time, though, LDAP is used to search for information in the directory.
|
|
|
|
The LDAP search operation allows some portion of the directory to
|
|
|
|
be searched for entries that match some criteria specified by a
|
|
|
|
search filter. Information can be requested from each entry that
|
|
|
|
matches the criteria.
|
|
|
|
|
|
|
|
For example, you might want to search the entire directory subtree
|
|
|
|
at and below {{EX:dc=example,dc=com}} for people with the name
|
|
|
|
{{EX:Barbara Jensen}}, retrieving the email address of each entry
|
|
|
|
found. LDAP lets you do this easily. Or you might want to search
|
|
|
|
the entries directly below the {{EX:st=California,c=US}} entry for
|
|
|
|
organizations with the string {{EX:Acme}} in their name, and that
|
|
|
|
have a fax number. LDAP lets you do this too. The next section
|
|
|
|
describes in more detail what you can do with LDAP and how it might
|
|
|
|
be useful to you.
|
|
|
|
|
|
|
|
{{How is the information protected from unauthorized access?}} Some
|
|
|
|
directory services provide no protection, allowing anyone to see
|
2005-03-25 11:48:04 +08:00
|
|
|
the information. LDAP provides a mechanism for a client to authenticate,
|
|
|
|
or prove its identity to a directory server, paving the way for
|
|
|
|
rich access control to protect the information the server contains.
|
|
|
|
LDAP also supports data security (integrity and confidentiality)
|
2000-08-31 13:52:55 +08:00
|
|
|
services.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2007-06-02 01:45:42 +08:00
|
|
|
H2: When should I use LDAP?
|
|
|
|
|
|
|
|
|
|
|
|
H2: When should I not use LDAP?
|
|
|
|
|
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H2: How does LDAP work?
|
|
|
|
|
2006-12-08 13:02:21 +08:00
|
|
|
LDAP utilizes a {{client-server model}}. One or more LDAP servers
|
|
|
|
contain the data making up the directory information tree ({{TERM:DIT}}).
|
|
|
|
The client connects to servers and asks it a question. The server
|
|
|
|
responds with an answer and/or with a pointer to where the client
|
|
|
|
can get additional information (typically, another LDAP server).
|
|
|
|
No matter which LDAP server a client connects to, it sees the same
|
|
|
|
view of the directory; a name presented to one LDAP server references
|
|
|
|
the same entry it would at another LDAP server. This is an important
|
|
|
|
feature of a global directory service.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
H2: What about X.500?
|
|
|
|
|
|
|
|
Technically, {{TERM:LDAP}} is a directory access protocol to an
|
|
|
|
{{TERM:X.500}} directory service, the {{TERM:OSI}} directory service.
|
2002-06-15 09:00:50 +08:00
|
|
|
Initially, LDAP clients accessed gateways to the X.500 directory service.
|
|
|
|
This gateway ran LDAP between the client and gateway and X.500's
|
|
|
|
{{TERM[expand]DAP}} ({{TERM:DAP}}) between the gateway and the
|
2001-05-12 14:15:42 +08:00
|
|
|
X.500 server. DAP is a heavyweight protocol that operates over a
|
|
|
|
full OSI protocol stack and requires a significant amount of
|
|
|
|
computing resources. LDAP is designed to operate over
|
|
|
|
{{TERM:TCP}}/{{TERM:IP}} and provides most of the functionality of
|
|
|
|
DAP at a much lower cost.
|
|
|
|
|
|
|
|
While LDAP is still used to access X.500 directory service via
|
|
|
|
gateways, LDAP is now more commonly directly implemented in X.500
|
|
|
|
servers.
|
|
|
|
|
2006-12-08 13:02:21 +08:00
|
|
|
The Standalone LDAP Daemon, or {{slapd}}(8), can be viewed as a
|
2001-05-12 14:15:42 +08:00
|
|
|
{{lightweight}} X.500 directory server. That is, it does not
|
2005-03-25 11:48:04 +08:00
|
|
|
implement the X.500's DAP nor does it support the complete X.500
|
|
|
|
models.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
If you are already running a X.500 DAP service and you want to
|
|
|
|
continue to do so, you can probably stop reading this guide. This
|
|
|
|
guide is all about running LDAP via {{slapd}}(8), without running
|
|
|
|
X.500 DAP. If you are not running X.500 DAP, want to stop running
|
|
|
|
X.500 DAP, or have no immediate plans to run X.500 DAP, read on.
|
|
|
|
|
|
|
|
It is possible to replicate data from an LDAP directory server to
|
|
|
|
a X.500 DAP {{TERM:DSA}}. This requires an LDAP/DAP gateway.
|
2006-12-08 11:17:38 +08:00
|
|
|
OpenLDAP Software does not include such a gateway.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
|
2002-06-14 20:38:32 +08:00
|
|
|
H2: What is the difference between LDAPv2 and LDAPv3?
|
2001-05-12 14:15:42 +08:00
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
LDAPv3 was developed in the late 1990's to replace LDAPv2.
|
2002-01-20 11:32:48 +08:00
|
|
|
LDAPv3 adds the following features to LDAP:
|
2001-05-12 14:15:42 +08:00
|
|
|
|
2005-03-25 11:38:59 +08:00
|
|
|
- Strong authentication and data security services via {{TERM:SASL}}
|
|
|
|
- Certificate authentication and data security services via {{TERM:TLS}} (SSL)
|
2001-05-12 14:15:42 +08:00
|
|
|
- Internationalization through the use of Unicode
|
|
|
|
- Referrals and Continuations
|
|
|
|
- Schema Discovery
|
2002-10-06 11:32:43 +08:00
|
|
|
- Extensibility (controls, extended operations, and more)
|
2001-05-12 14:15:42 +08:00
|
|
|
|
2005-03-25 11:38:59 +08:00
|
|
|
LDAPv2 is historic ({{REF:RFC3494}}). As most {{so-called}} LDAPv2
|
|
|
|
implementations (including {{slapd}}(8)) do not conform to the
|
2007-08-07 00:08:05 +08:00
|
|
|
LDAPv2 technical specification, interoperability amongst
|
2005-03-25 11:38:59 +08:00
|
|
|
implementations claiming LDAPv2 support is limited. As LDAPv2
|
|
|
|
differs significantly from LDAPv3, deploying both LDAPv2 and LDAPv3
|
|
|
|
simultaneously is quite problematic. LDAPv2 should be avoided.
|
2003-03-10 23:41:55 +08:00
|
|
|
LDAPv2 is disabled by default.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
2007-06-02 01:45:42 +08:00
|
|
|
H2: LDAP vs RDBMS
|
|
|
|
|
2007-08-06 06:06:33 +08:00
|
|
|
This question is raised many times, in different forms. The most common,
|
|
|
|
however, is: {{Why doesn't OpenLDAP drop Berkeley DB and use a relational
|
|
|
|
database management system (RDBM) instead?}} In general, expecting that the
|
|
|
|
sophisticated algorithms implemented by commercial-grade RDBM would make
|
|
|
|
{{OpenLDAP}} be faster or somehow better and, at the same time, permitting
|
|
|
|
sharing of data with other applications.
|
|
|
|
|
|
|
|
The short answer is that use of an embedded database and custom indexing system
|
|
|
|
allows OpenLDAP to provide greater performance and scalability without loss of
|
|
|
|
reliability. OpenLDAP, since release 2.1, in its main storage-oriented backends
|
|
|
|
(back-bdb and, since 2.2, back-hdb) uses Berkeley DB concurrent / transactional
|
|
|
|
database software. This is the same software used by leading commercial
|
|
|
|
directory software.
|
|
|
|
|
|
|
|
Now for the long answer. We are all confronted all the time with the choice
|
|
|
|
RDBMs vs. directories. It is a hard choice and no simple answer exists.
|
|
|
|
|
|
|
|
It is tempting to think that having a RDBMS backend to the directory solves all
|
|
|
|
problems. However, it is a pig. This is because the data models are very
|
|
|
|
different. Representing directory data with a relational database is going to
|
|
|
|
require splitting data into multiple tables.
|
|
|
|
|
|
|
|
Think for a moment about the person objectclass. Its definition requires
|
|
|
|
attribute types objectclass, sn and cn and allows attribute types userPassword,
|
|
|
|
telephoneNumber, seeAlso and description. All of these attributes are multivalued,
|
|
|
|
so a normalization requires putting each attribute type in a separate table.
|
|
|
|
|
|
|
|
Now you have to decide on appropriate keys for those tables. The primary key
|
|
|
|
might be a combination of the DN, but this becomes rather inefficient on most
|
|
|
|
database implementations.
|
|
|
|
|
|
|
|
The big problem now is that accessing data from one entry requires seeking on
|
|
|
|
different disk areas. On some applications this may be OK but in many
|
|
|
|
applications performance suffers.
|
|
|
|
|
|
|
|
The only attribute types that can be put in the main table entry are those that
|
|
|
|
are mandatory and single-value. You may add also the optional single-valued
|
|
|
|
attributes and set them to NULL or something if not present.
|
|
|
|
|
|
|
|
But wait, the entry can have multiple objectclasses and they are organized in
|
|
|
|
an inheritance hierarchy. An entry of objectclass organizationalPerson now has
|
|
|
|
the attributes from person plus a few others and some formerly optional attribute
|
|
|
|
types are now mandatory.
|
|
|
|
|
|
|
|
What to do? Should we have different tables for the different objectclasses?
|
|
|
|
This way the person would have an entry on the person table, another on
|
|
|
|
organizationalPerson, etc. Or should we get rid of person and put everything on
|
|
|
|
the second table?
|
|
|
|
|
|
|
|
But what do we do with a filter like (cn=*) where cn is an attribute type that
|
|
|
|
appears in many, many objectclasses. Should we search all possible tables for
|
|
|
|
matching entries? Not very attractive.
|
|
|
|
|
|
|
|
Once this point is reached, three approaches come to mind. One is to do full
|
|
|
|
normalization so that each attribute type, no matter what, has its own separate
|
|
|
|
table. The simplistic approach where the DN is part of the primary key is
|
|
|
|
extremely wasteful, and calls for an approach where the entry has a unique
|
|
|
|
numeric id that is used instead for the keys and a main table that maps DNs to
|
|
|
|
ids. The approach, anyway, is very inefficient when several attribute types from
|
|
|
|
one or more entries are requested. Such a database, though cumbersomely,
|
|
|
|
can be managed from SQL applications.
|
|
|
|
|
|
|
|
The second approach is to put the whole entry as a blob in a table shared by all
|
|
|
|
entries regardless of the objectclass and have additional tables that act as
|
|
|
|
indices for the first table. Index tables are not database indices, but are
|
|
|
|
fully managed by the LDAP server-side implementation. However, the database
|
|
|
|
becomes unusable from SQL. And, thus, a fully fledged database system provides
|
|
|
|
little or no advantage. The full generality of the database is unneeded.
|
|
|
|
Much better to use something light and fast, like Berkeley DB.
|
|
|
|
|
|
|
|
A completely different way to see this is to give up any hopes of implementing
|
|
|
|
the directory data model. In this case, LDAP is used as an access protocol to
|
|
|
|
data that provides only superficially the directory data model. For instance,
|
|
|
|
it may be read only or, where updates are allowed, restrictions are applied,
|
|
|
|
such as making single-value attribute types that would allow for multiple values.
|
|
|
|
Or the impossibility to add new objectclasses to an existing entry or remove
|
|
|
|
one of those present. The restrictions span the range from allowed restrictions
|
|
|
|
(that might be elsewhere the result of access control) to outright violations of
|
|
|
|
the data model. It can be, however, a method to provide LDAP access to preexisting
|
2007-08-07 00:08:05 +08:00
|
|
|
data that is used by other applications. But in the understanding that we don't
|
|
|
|
really have a "directory".
|
2007-08-06 06:06:33 +08:00
|
|
|
|
|
|
|
Existing commercial LDAP server implementations that use a relational database
|
|
|
|
are either from the first kind or the third. I don't know of any implementation
|
|
|
|
that uses a relational database to do inefficiently what BDB does efficiently.
|
|
|
|
For those who are interested in "third way" (exposing EXISTING data from RDBMS
|
|
|
|
as LDAP tree, having some limitations compared to classic LDAP model, but making
|
|
|
|
it possible to interoperate between LDAP and SQL applications):
|
|
|
|
|
|
|
|
OpenLDAP includes back-sql - the backend that makes it possible. It uses ODBC +
|
|
|
|
additional metainformation about translating LDAP queries to SQL queries in your
|
|
|
|
RDBMS schema, providing different levels of access - from read-only to full
|
|
|
|
access depending on RDBMS you use, and your schema.
|
|
|
|
|
|
|
|
For more information on concept and limitations, see {{slapd-sql}}(5) man page,
|
|
|
|
or the {{SECT: Backends}} section. There are also several examples for several
|
|
|
|
RDBMSes in {{F:back-sql/rdbms_depend/*}} subdirectories.
|
|
|
|
|
|
|
|
TO REFERENCE:
|
2007-06-19 07:01:15 +08:00
|
|
|
|
|
|
|
http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database
|
|
|
|
http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database_part
|
2007-06-02 01:45:42 +08:00
|
|
|
|
1999-04-24 07:00:44 +08:00
|
|
|
H2: What is slapd and what can it do?
|
|
|
|
|
2001-05-12 14:15:42 +08:00
|
|
|
{{slapd}}(8) is an LDAP directory server that runs on many different
|
|
|
|
platforms. You can use it to provide a directory service of your
|
|
|
|
very own. Your directory can contain pretty much anything you want
|
|
|
|
to put in it. You can connect it to the global LDAP directory
|
|
|
|
service, or run a service all by yourself. Some of slapd's more
|
|
|
|
interesting features and capabilities include:
|
|
|
|
|
|
|
|
{{B:LDAPv3}}: {{slapd}} implements version 3 of {{TERM[expand]LDAP}}.
|
2006-12-10 00:53:09 +08:00
|
|
|
{{slapd}} supports LDAP over both {{TERM:IPv4}} and {{TERM:IPv6}}
|
|
|
|
and Unix {{TERM:IPC}}.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
{{B:{{TERM[expand]SASL}}}}: {{slapd}} supports strong authentication
|
2005-03-25 11:48:04 +08:00
|
|
|
and data security (integrity and confidentiality) services through
|
2006-12-08 04:31:18 +08:00
|
|
|
the use of SASL. {{slapd}}'s SASL implementation utilizes {{PRD:Cyrus
|
|
|
|
SASL}} software which supports a number of mechanisms including
|
|
|
|
{{TERM:DIGEST-MD5}}, {{TERM:EXTERNAL}}, and {{TERM:GSSAPI}}.
|
2005-03-25 11:48:04 +08:00
|
|
|
|
|
|
|
{{B:{{TERM[expand]TLS}}}}: {{slapd}} supports certificate-based
|
|
|
|
authentication and data security (integrity and confidentiality)
|
|
|
|
services through the use of TLS (or SSL). {{slapd}}'s TLS
|
2001-05-12 14:15:42 +08:00
|
|
|
implementation utilizes {{PRD:OpenSSL}} software.
|
|
|
|
|
2003-12-03 03:41:19 +08:00
|
|
|
{{B:Topology control}}: {{slapd}} can be configured to restrict
|
|
|
|
access at the socket layer based upon network topology information.
|
|
|
|
This feature utilizes {{TCP wrappers}}.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
|
|
|
{{B:Access control}}: {{slapd}} provides a rich and powerful access
|
|
|
|
control facility, allowing you to control access to the information
|
|
|
|
in your database(s). You can control access to entries based on
|
2000-07-30 23:18:10 +08:00
|
|
|
LDAP authorization information, {{TERM:IP}} address, domain name
|
2005-03-25 11:38:59 +08:00
|
|
|
and other criteria. {{slapd}} supports both {{static}} and {{dynamic}}
|
|
|
|
access control information.
|
2000-07-30 23:18:10 +08:00
|
|
|
|
|
|
|
{{B:Internationalization}}: {{slapd}} supports Unicode and language
|
|
|
|
tags.
|
|
|
|
|
2002-06-15 09:00:50 +08:00
|
|
|
{{B:Choice of database backends}}: {{slapd}} comes with a variety
|
2002-06-15 05:19:42 +08:00
|
|
|
of different database backends you can choose from. They include
|
|
|
|
{{TERM:BDB}}, a high-performance transactional database backend;
|
2006-02-17 17:24:57 +08:00
|
|
|
{{TERM:HDB}}, a hierarchical high-performance transactional
|
|
|
|
backend; {{SHELL}}, a backend interface to arbitrary shell scripts;
|
|
|
|
and PASSWD, a simple backend interface to the {{passwd}}(5) file.
|
2006-12-07 12:09:40 +08:00
|
|
|
The BDB and HDB backends utilize {{ORG:Oracle}} {{PRD:Berkeley
|
2006-02-17 17:24:57 +08:00
|
|
|
DB}}.
|
2000-07-30 23:18:10 +08:00
|
|
|
|
2001-05-12 14:15:42 +08:00
|
|
|
{{B:Multiple database instances}}: {{slapd}} can be configured to
|
|
|
|
serve multiple databases at the same time. This means that a single
|
|
|
|
{{slapd}} server can respond to requests for many logically different
|
2002-06-15 05:19:42 +08:00
|
|
|
portions of the LDAP tree, using the same or different database
|
|
|
|
backends.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
2003-12-16 14:52:52 +08:00
|
|
|
{{B:Generic modules API}}: If you require even more customization,
|
2001-05-12 14:15:42 +08:00
|
|
|
{{slapd}} lets you write your own modules easily. {{slapd}} consists
|
|
|
|
of two distinct parts: a front end that handles protocol communication
|
|
|
|
with LDAP clients; and modules which handle specific tasks such as
|
2005-03-25 11:38:59 +08:00
|
|
|
database operations. Because these two pieces communicate via a
|
2001-05-12 14:15:42 +08:00
|
|
|
well-defined {{TERM:C}} {{TERM:API}}, you can write your own
|
|
|
|
customized modules which extend {{slapd}} in numerous ways. Also,
|
|
|
|
a number of {{programmable database}} modules are provided. These
|
|
|
|
allow you to expose external data sources to {{slapd}} using popular
|
2006-12-08 05:50:15 +08:00
|
|
|
programming languages ({{PRD:Perl}}, {{shell}}, {{TERM:SQL}}, and
|
2001-05-12 14:15:42 +08:00
|
|
|
{{PRD:TCL}}).
|
|
|
|
|
2002-06-15 05:19:42 +08:00
|
|
|
{{B:Threads}}: {{slapd}} is threaded for high performance. A single
|
2005-03-25 11:38:59 +08:00
|
|
|
multi-threaded {{slapd}} process handles all incoming requests using
|
|
|
|
a pool of threads. This reduces the amount of system overhead
|
2002-06-15 09:00:50 +08:00
|
|
|
required while providing high performance.
|
2001-05-12 14:15:42 +08:00
|
|
|
|
2003-12-03 03:41:19 +08:00
|
|
|
{{B:Replication}}: {{slapd}} can be configured to maintain shadow
|
|
|
|
copies of directory information. This {{single-master/multiple-slave}}
|
2000-07-30 23:18:10 +08:00
|
|
|
replication scheme is vital in high-volume environments where a
|
|
|
|
single {{slapd}} just doesn't provide the necessary availability
|
2006-12-08 11:17:38 +08:00
|
|
|
or reliability. {{slapd}} includes support for {{LDAP Sync}}-based
|
|
|
|
replication.
|
2003-12-03 03:41:19 +08:00
|
|
|
|
2003-12-16 14:52:52 +08:00
|
|
|
{{B:Proxy Cache}}: {{slapd}} can be configured as a caching
|
|
|
|
LDAP proxy service.
|
2000-07-30 23:18:10 +08:00
|
|
|
|
2001-05-12 14:15:42 +08:00
|
|
|
{{B:Configuration}}: {{slapd}} is highly configurable through a
|
|
|
|
single configuration file which allows you to change just about
|
|
|
|
everything you'd ever want to change. Configuration options have
|
1999-04-24 07:00:44 +08:00
|
|
|
reasonable defaults, making your job much easier.
|
|
|
|
|