In this configuration, you run a slapd which provides directory service
for your local domain and configure it to return referrals to a
-{{superior}} service capable of requests outside your local domain.
+{{superior}} service capable of handling requests outside your local domain.
You may run this service yourself or use one provided to you.
This configuration is shown in Figure 3.2.
!import "config_repl.gif"; align="center"; title="Replicated Directory Services"
FT[align="Center"] Figure 3.3: Replicated Directory Services
-This configuration can be used in conjunction with either of first
+This configuration can be used in conjunction with either of the first
two configurations in situations where a single slapd does not
provide the required reliability or availability.
> directory /usr/local/var/openldap-data
-Finally, you need to specify which indexes you want to build. This
+Finally, you need to specify which indices you want to build. This
is done by one or more index options.
> index {<attrlist> | default} [pres,eq,approx,sub,none]
> index cn,sn,uid pres,eq,sub
> index objectClass eq
-This would create presence, equality and substring indexes for
+This would create presence, equality and substring indices for
the {{EX:cn}}, {{EX:sn}}, and {{EX:uid}} attributes and an equality
-index for the {{EX:objectClass}} attribute. See the configuration
-file section for more information on this option.
+index for the {{EX:objectClass}} attribute. See
+{{SECT:The slapd Configuration File}} section
+for more information on this option.
H3: The {{EX:slapadd}} program
Once you've configured things to your liking, you create the primary
-database and associated indexes by running the {{slapadd}}(8)
+database and associated indices by running the {{slapadd}}(8)
program:
> slapadd -l <inputfile> -f <slapdconfigfile>
> -f <slapdconfigfile>
Specifies the slapd configuration file that tells where to create
-the indexes, what indexes to create, etc.
+the indices, what indices to create, etc.
> -d <debuglevel>
use}}. The project makes {{releases}} as new features and bug
fixes come available. Though the project takes steps to improve
stablity of these releases, it is common for problems to arise
-only after {{release}}. The latest {{release}} which has
-demonstrated stability through general use.
+only after {{release}}. The {{Stable}} release is the latest
+{{release}} which has demonstrated stability through general use.
Users of OpenLDAP Software can choose, depending on their desire
for the {{latest features}} versus {{demonstrated stability}},
software packages. This section details commonly needed third party
software packages you might have to install. Note that some of
these third party packages may depend on additional software
-packages. Install each package per installation instructions
+packages. Install each package per the installation instructions
provided with it.
OpenLDAP's {{slapd}}(8) primary database backend, {{TERM:BDB}},
requires {{ORG[expand]Sleepycat}} {{PRD:Berkeley DB}}, version 4.
If not available at configure time, you will not be able build
-{{slapd}}(8) with primary database backend.
+{{slapd}}(8) with this primary database backend.
Your operating system may provide {{PRD:Berkeley DB}}, version 4,
in the base system or as an optional software component. If not,
is required if you wish to use the {{TERM:BDB}} database backend.
OpenLDAP's {{slapd}}(8) LDBM backend supports a variety of data
-base managers {{PRD:Berkeley DB}} and {{PRD:GDBM}}. {{PRD:GDBM}}
+base managers including {{PRD:Berkeley DB}} and {{PRD:GDBM}}. {{PRD:GDBM}}
is available from {{ORG:FSF}}'s download site
{{URL: ftp://ftp.gnu.org/pub/gnu/gdbm/}}.
H3: TCP Wrappers
-{{slapd}}(8) supports TCP wrappers (IP level access control filters)
-if preinstalled. Use of TCP wrappers or other IP-level access
+{{slapd}}(8) supports TCP Wrappers (IP level access control filters)
+if preinstalled. Use of TCP Wrappers or other IP-level access
filters (such as those provided by an IP-level firewall) is recommended
for servers containing non-public information.
> [[env] settings] ./configure [options]
As an example, let's assume that we want to install OpenLDAP with
-LDBM backend and TCP wrapper support. By default, LDBM
-is enabled and TCP wrappers is not. So, we just need to specify
-{{EX:--with-wrappers}} to include TCP wrapper support:
+BDB backend and TCP Wrappers support. By default, BDB
+is enabled and TCP Wrappers is not. So, we just need to specify
+{{EX:--with-wrappers}} to include TCP Wrappers support:
> ./configure --with-wrappers
setting with the {{EX:--prefix}} configure option, it will be installed
in the location you provided.
-Typically, the installation typically requires super-user priviledges.
+Typically, the installation requires {{super-user}} privileges.
From the top level OpenLDAP source directory, type:
> su root -c 'make install'
You should examine the output of this command carefully to make sure
everything is installed correctly. You will find the configuration files
for {{slapd}}(8) in {{F:/usr/local/etc/openldap}} by default. See the
-{{SECT:The slapd Configuration File}} chapter for additional information.
+chapter {{SECT:The slapd Configuration File}} for additional information.
H2: What is a directory service?
-A directory is specialized database optimized for reading, browsing
+A directory is a specialized database optimized for reading, browsing
and searching. 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 tuned to give quick-response to high-volume
+all. Directories are 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
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
-values depend on the attribute type is. For example, {{EX:cn}}
-attribute might be the value {{EX:Babs Jensen}}. A {{EX:mail}}
+values depend on the attribute type. For example, a {{EX:cn}}
+attribute might contain the value {{EX:Babs Jensen}}. A {{EX:mail}}
attribute might contain the value "{{EX:babs@example.com}}". A
{{EX:jpegPhoto}} attribute would contain a photograph in the JPEG
(binary) format.
{{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
-boundaries. Entries representing countries appeared at the top of
+boundaries. Entries representing countries appear at the top of
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
The tree may also be arranged based upon Internet domain names.
This naming approach is becoming increasing popular as it allows
-for directory services to be locating using the {{DNS}}.
+for directory services to be located using the {{DNS}}.
Figure 1.2 shows an example LDAP directory tree using domain-based
naming.
Technically, {{TERM:LDAP}} is a directory access protocol to an
{{TERM:X.500}} directory service, the {{TERM:OSI}} directory service.
-Initially, LDAP clients accessed gateways to 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
+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
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
H2: What is the difference between LDAPv2 and LDAPv3?
-LDAPv3 was developed in late 1990's to replace LDAPv2.
+LDAPv3 was developed in the late 1990's to replace LDAPv2.
LDAPv3 adds the following features to LDAP:
- Strong Authentication via {{TERM:SASL}}
- - Integrity and Confidential Protections via {{TERM:TLS}} (SSL)
+ - Integrity and Confidentiality Protection via {{TERM:TLS}} (SSL)
- Internationalization through the use of Unicode
- Referrals and Continuations
- Extensibility (controls and extended operations)
{{B:Internationalization}}: {{slapd}} supports Unicode and language
tags.
-{{B:Choice of databases backends}}: {{slapd}} comes with a variety
+{{B:Choice of database backends}}: {{slapd}} comes with a variety
of different database backends you can choose from. They include
{{TERM:BDB}}, a high-performance transactional database backend;
{{TERM:LDBM}}, a lightweight DBM based backend; {{SHELL}}, a backend
{{B:Threads}}: {{slapd}} is threaded for high performance. A single
multi-threaded {{slapd}} process handles all incoming requests
using a pool of threads. This reduces the amount of system overhead
-required while proving high performance.
+required while providing high performance.
{{B:Replication}}: {{slapd}} can be configured to maintain replica
copies of its database. This {{single-master/multiple-slave}}
The following is a quick start guide to OpenLDAP 2.1 software,
including the stand-alone LDAP daemon, {{slapd}}(8).
-It is meant to step you through the basic steps needed to install
+It is meant to walk you through the basic steps needed to install
and configure OpenLDAP software. It should be used in conjunction
with the other chapters of this document, manual pages, and
other materials provided with the distribution (e.g. the {{F:INSTALL}}
+{{B: Run {{EX:configure}}}}
. You will need to run the provided {{EX:configure}} script to
-{{configure}} to the distribution for building on your system. The
+{{configure}} the distribution for building on your system. The
{{EX:configure}} script accepts many command line options that enable or
disable optional software features. Usually the defaults are okay,
but you may want to change them. To get a complete list of options
..{{EX:./configure --help}}
-. However, given that you using this guide, we'll assume you'll
-are brave enough to just let {{EX:configure}} to determine
+. However, given that you are using this guide, we'll assume you
+are brave enough to just let {{EX:configure}} determine
what's best:
..{{EX:./configure}}
.{{S: }}
+{{B:Install the software}}.
-. You are now ready to install the software, this usually requires
-{{super-user}} privledges:
+. You are now ready to install the software; this usually requires
+{{super-user}} privileges:
..{{EX:su root -c 'make install'}}
. Use your favorite editor to edit the provided {{slapd.conf}}(5)
example (usually installed as {{F:/usr/local/etc/openldap/slapd.conf}})
-to contain an BDB database definition of the form:
+to contain a BDB database definition of the form:
..{{EX:database bdb}}
..{{EX:suffix "dc=<MY-DOMAIN>,dc=<COM>"}}
{{EX:rootdn}} configuration directive). It is highly recommended
that you establish controls to restrict access to authorized users.
Access controls are discussed in the {{SECT:Access Control}} section
-of the {{SECT:The slapd Configuration File}} chapter. You are also
-encouraged to read {{SECT:Security Considerations}}, {{SECT:Using
+of {{SECT:The slapd Configuration File}} chapter. You are also
+encouraged to read the {{SECT:Security Considerations}}, {{SECT:Using
SASL}} and {{SECT:Using TLS}} sections.
The following chapters provide more detailed information on making,
as a special {{referral}} object at the delegate point.
The referral object acts as a delegation point, gluing two services
together.
-This mechanism allows for hierarchical directory services to to be
+This mechanism allows for hierarchical directory services to be
constructed.
A referral object has a structural object class of
{{EX:referral}} directive. The value is a list of {{TERM:URI}}s
referring to superior directory services. For servers without
immediate superiors, such as for {{EX:a.example.net}} in the example
-above, the server can be configured to use directory service with
+above, the server can be configured to use a directory service with
{{global knowledge}}, such as the {{OpenLDAP Root Service}}
({{URL:http://www.openldap.org/faq/index.cgi?file=393}}).
> referral ldap://a.example.net/
-The server uses this information to generate referrals to
-operations acting upon operations not within or subordinate
+The server uses this information to generate referrals for
+operations acting upon entries not within or subordinate
to any of the naming contexts held by the server.
For those familiar with X.500, this use of the {{EX:ref}} attribute
This option sets the slurpd debug level to {{EX: <level>}}. When
level is a `?' character, the various debugging levels are
-printed and slapd exits, regardless of any other options
+printed and slurpd exits, regardless of any other options
you give it. Current debugging levels (a subset of slapd's
debugging levels) are
In general, you should copy each file found in the database
{{EX: directory}} unless you know it is not used by {{slapd}}(8).
-Note: The copy process assumes homogeneous servers with
-identically configured OpenLDAP installations.
+Note: This copy process assumes homogeneous servers with
+identically configured OpenLDAP installations. Alternatively,
+you may use {{slapcat}} to output the master's database in LDIF
+format and use the LDIF with {{slapadd}} to populate the
+slave. Using LDIF avoids any potential incompatibilities due
+to differing server architectures or software configurations.
+See the {{SECT:Database Creation and Maintenance Tools}}
+chapter for details on these tools.
H3: Configure the master slapd for replication
Some mechanisms, such as PLAIN and LOGIN, offer no greater security over
LDAP "simple" authentication. Like "simple" authentication, such
mechanisms should not be used unless you have adequate security
-protections in place. It is recommended that these mechanism be
+protections in place. It is recommended that these mechanisms be
used only in conjunction with {{TERM[expand]TLS}} (TLS). Use of
PLAIN and LOGIN are not discussed further in this document.
of DIGEST-MD5. Use of {{SECT:DIGEST-MD5}} is discussed below.
The KERBEROS_V4 mechanism utilizes Kerberos IV to provide secure
-authentication services. There are also GSSAPI based mechanisms
+authentication services. There is also a GSSAPI based mechanism
which is generally used in conjunction with Kerberos V. Kerberos
is viewed as a secure, distributed authentication system suitable
for both small and large enterprises. Use of {{SECT:KERBEROS_V4}}
This section describes the use of the SASL KERBEROS_V4 mechanism
with OpenLDAP. It will be assumed that you are familiar with the
-workings of Kerberos IV security system, and that your site has
+workings of the Kerberos IV security system, and that your site has
Kerberos IV deployed. Your users should be familiar with
authentication policy, how to receive credentials in
a Kerberos ticket cache, and how to refresh expired credentials.
matched a string in parenthesis in the search pattern is stored in
the variable "$1". That variable "$1" can appear in the replacement
pattern, and will be replaced by the string from the authentication
-request DN. If there were multiple sets of parenthesis in the search
+request DN. If there were multiple sets of parentheses in the search
pattern, the variables $2, $3, etc are used.
For example, suppose the user's authentication identity is written
You are, of course, free to design a hierarchy suitable to your
organizational needs under your organization's OID. No matter
what hierarchy you choose, you should maintain a registry of
-assignments you make. This can be a simple flat file or a
+assignments you make. This can be a simple flat file or
something more sophisticated such as the {{OpenLDAP OID Registry}}
({{URL:http://www.openldap.org/faq/index.cgi?file=197}}).
.{{Under no circumstances should you use a fictitious OID!}}
To obtain a fully registered OID at {{no cost}}, apply for
-an OID under {{ORG[expand]IANA}} (IANA) maintained
+an OID under the {{ORG[expand]IANA}} (IANA) maintained
{{Private Enterprise}} arch. Any private enterprise (organization)
may request an OID to be assigned under this arch. Just fill
out the {{ORG:IANA}} form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
and your official OID will be sent to you usually within a few days.
-Your base OID will be something like {{EX:1.3.6.1.4.1.X}} were {{EX:X}}
+Your base OID will be something like {{EX:1.3.6.1.4.1.X}} where {{EX:X}}
is an integer.
Note: Don't let the "MIB/SNMP" statement on the IANA page confuse you.
where whsp is a space ('{{EX: }}'), numericoid is a globally unique
OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or
more names, woid is either the name or OID optionally followed
-length specifier (e.g {{EX:{10}}}).
+by a length specifier (e.g {{EX:{10}}}).
For example, the attribute types {{EX:name}} and {{EX:cn}} are defined
in {{F:core.schema}} as:
{{slapd}}(8) returns the first listed name when returning results.
The first attribute, {{EX:name}}, holds values of {{EX:directoryString}}
-(UTF-8 encoded Unicode) syntax. The syntax are specified by OID
+(UTF-8 encoded Unicode) syntax. The syntax is specified by OID
(1.3.6.1.4.1.1466.115.121.1.15 identifies the directoryString
syntax). A length recommendation of 32768 is specified. Servers
should support values of this length, but may support longer values
and their use in defining schema elements:
> objectIdentifier myOID 1.1
-> objectIdentifier mySNMP myOrgOID:1
-> objectIdentifier myLDAP myOrgOID:2
-> objectIdentifier myAttributeType myOrgLDAP:1
-> objectIdentifier myObjectClass myOrgLDAP:2
+> objectIdentifier mySNMP myOID:1
+> objectIdentifier myLDAP myOID:2
+> objectIdentifier myAttributeType myLDAP:1
+> objectIdentifier myObjectClass myLDAP:2
> attributetype ( myAttributeType:3 NAME 'myPhotoURI'
> DESC 'URI and optional label referring to a photo'
> SUP labeledURI )
information is specified first, followed by information associated
with a particular backend type, which is then followed by information
associated with a particular database instance. Global directives can
-be overridden in a backend and/or database directives, backend directives
+be overridden in backend and/or database directives, and backend directives
can be overridden by database directives.
Blank lines and comment lines beginning with a '{{EX:#}}' character
H2: Configuration File Directives
This section details commonly used configuration directives. For
-a complete list, see {{slapd.conf}}(5) manual page. This section
+a complete list, see the {{slapd.conf}}(5) manual page. This section
separates the configuration file directives into global,
backend-specific and data-specific categories, describing each
directive and its default value (if any), and giving an example of
H4: backend <type>
This directive marks the beginning of a backend declaration.
-{{EX:<type>}} should be one of {{EX:bdb}} or one of other
+{{EX:<type>}} should be one of the
supported backend types listed in Table 5.2.
!block table; align=Center; coltags="EX,N"; \
\Example:
-> database bdb
+> backend bdb
This marks the beginning of a new {{TERM:BDB}} backend
definition.
This directive marks the beginning of a database instance
declaration.
-{{EX:<type>}} should be one of {{EX:bdb}} or one of the other
+{{EX:<type>}} should be one of the
supported backend types listed in Table 5.2.
\Example:
SASL-based Example:
-> rootdn "uid=root@EXAMPLE.COM"
+> rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
H4: rootpw <password>
SASL-based Example:
-> updatedn "uid=slurpd@EXAMPLE.COM"
+> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
-See the {{SECT:Replication}} chapter for more information on how to
-use this directive.
+See the {{SECT:Replication with slurpd}} chapter for more information
+on how to use this directive.
H4: updateref <URL>
H4: directory <directory>
This directive specifies the directory where the BDB files
-containing the database and associated indexes live.
+containing the database and associated indices live.
\Default:
underlying database method, this directive is ignored without
comment. Increasing this number uses more memory but can
cause a dramatic performance increase, especially during
-modifies or when building indexes.
+modifies or when building indices.
\Default:
H4: dbnosync
-This option causes on-disk database contents not be immediately
+This option causes on-disk database contents to not be immediately
synchronized with in memory changes upon change. Enabling this option
-may improve performance at the expense of data security.
+may improve performance at the expense of data integrity.
H4: directory <directory>
This directive specifies the directory where the LDBM files
-containing the database and associated indexes live.
+containing the database and associated indices live.
\Default:
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
-This directive specifies the indexes to maintain for the given
+This directive specifies the indices to maintain for the given
attribute. If only an {{EX:<attrlist>}} is given, the default
-indexes are maintained.
+indices are maintained.
\Example:
> <access directive> ::= access to <what>
> [by <who> <access> <control>]+
-> <what> ::= * | [ dn[.<target style>]=<regex>]
+> <what> ::= * | [ dn[.<dn style>]=<regex>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
-> <target style> ::= regex | base | one | subtree | children
+> <dn style> ::= regex | exact | base | one | subtree | children
> <attrlist> ::= <attr> | <attr> , <attrlist>
> <attr> ::= <attrname> | entry | children
> <who> ::= [* | anonymous | users | self |
-> dn[.<subject style>]=<regex>]
+> dn[.<dn style>]=<regex>]
> [dnattr=<attrname> ]
> [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
> [peername[.<basic style>]=<regex>]
> [sockurl[.<basic style>]=<regex>]
> [set=<setspec>]
> [aci=<attrname>]
-> <subject style> ::= regex | exact | base | one | subtree | children
> <basic style> ::= regex | exact
> <access> ::= [self]{<level>|<priv>}
> <level> ::= none | auth | compare | search | read | write
entities are granted access, and the {{EX:<access>}} part specifies
the access granted. Multiple {{EX:<who> <access> <control>}} triplets
are supported, allowing many entities to be granted different
-access to the same set of entries and attributes.
+access to the same set of entries and attributes. Not all of these
+access control options are described here; for more details see
+the {{slapd.access}}(5) man page.
H3: What to control access to
When evaluating whether some requester should be given access to
an entry and/or attribute, slapd compares the entry and/or attribute
to the {{EX:<what>}} selectors given in the configuration file.
-For each entry, access control provided in the database which holds
+For each entry, access controls provided in the database which holds
the entry (or the first database if not held in any database) apply
-first, followed by the global access directivies. Within this
+first, followed by the global access directives. Within this
priority, access directives are examined in the order in which they
appear in the config file. Slapd stops with the first {{EX:<what>}}
selector that matches the entry and/or attribute. The corresponding
E: 4. access to * by * read
Line 1 is a comment. Line 2 includes another config file
-which containing {{core}} schema definitions.
+which contains {{core}} schema definitions.
The {{EX:referral}} directive on line 3
means that queries not local to one of the databases defined
below will be referred to the LDAP server running on the
entries (after any applicable database-specific access
controls).
-The next section of the configuration file defines an BDB
+The next section of the configuration file defines a BDB
backend that will handle queries for things in the
"dc=example,dc=com" portion of the tree. The
database is to be replicated to two slave slapds, one on
-truelies, the other on judgmentday. Indexes are to be
+truelies, the other on judgmentday. Indices are to be
maintained for several attributes, and the {{EX:userPassword}}
attribute is to be protected from unauthorized access.
for queries to pass to this database. Line 8 specifies the directory
in which the database files will live.
-Lines 9 and 10 identify the database "super user" entry and associated
+Lines 9 and 10 identify the database {{super-user}} entry and associated
password. This entry is not subject to access control or size or
time limit restrictions.
Lines 11 through 18 are for replication. Line 12 specifies the
-replication log file (where changes to the database are logged \-
+replication log file (where changes to the database are logged -
this file is written by slapd and read by slurpd). Lines 13 through
15 specify the hostname and port for a replicated host, the DN to
bind as when performing updates, the bind method (simple) and the
a second replication site. See the {{SECT:Replication with slurpd}}
chapter for more information on these directives.
-Lines 20 through 22 indicate the indexes to maintain for various
+Lines 20 through 22 indicate the indices to maintain for various
attributes.
-Lines 24 through 32 specify access control for entries in the this
+Lines 24 through 32 specify access control for entries in this
database. As this is the first database, the controls also apply
to entries not held in any database (such as the Root DSE). For
all applicable entries, the {{EX:userPassword}} attribute is writable
projects / openldap / commitdiff