Commits (41)
......@@ -147,6 +147,7 @@ libraries/liblunicode/ure.c
libraries/liblunicode/ure.h
libraries/liblunicode/urestubs.c
libraries/liblunicode/version.c
libraries/liblutil/slapdmsg.res
libraries/liblutil/version.c
libraries/librewrite/rewrite
libraries/librewrite/version.c
......
stages:
- build
build:
build1:
stage: build
script:
- apt update
- apt install -y build-essential pkg-config automake libsasl2-dev heimdal-multidev libssl-dev libltdl-dev groff-base unixodbc-dev libwiredtiger-dev libperl-dev
- DEBIAN_FRONTEND=noninteractive apt install -y build-essential pkg-config automake libsasl2-dev heimdal-multidev libssl-dev libltdl-dev groff-base unixodbc-dev libwiredtiger-dev libperl-dev heimdal-kdc libsasl2-modules-gssapi-heimdal sasl2-bin
- autoreconf
- ./configure --enable-backends=mod --enable-overlays=mod --enable-modules --enable-dynamic --disable-ndb --disable-asyncmeta
- make depend
......@@ -18,3 +18,21 @@ build:
expire_in: '1 week'
paths:
- tests/testrun/
build2:
stage: build
script:
- apt update
- DEBIAN_FRONTEND=noninteractive apt install -y build-essential pkg-config automake libsasl2-dev libltdl-dev groff-base unixodbc-dev libwiredtiger-dev libperl-dev krb5-user krb5-kdc krb5-admin-server libsasl2-modules-gssapi-mit sasl2-bin libgnutls28-dev
- autoreconf
- ./configure --enable-backends=mod --enable-overlays=mod --disable-autoca --enable-modules --enable-dynamic --disable-ndb --disable-asyncmeta
- make depend
- make
- ulimit -n 4096 # back-monitor takes a while scanning a long connections array
- make test
artifacts:
name: testdir
when: on_failure
expire_in: '1 week'
paths:
- tests/testrun/
This diff is collapsed.
This diff is collapsed.
......@@ -5,7 +5,7 @@
H1: Changes Since Previous Release
The following sections attempt to summarize the new features and changes in OpenLDAP
software since the 2.3.x release and the OpenLDAP Admin Guide.
software since the 2.4.x release and the OpenLDAP Admin Guide.
H2: New Guide Sections
......@@ -24,7 +24,7 @@ asked on the OpenLDAP mailing lists and scenarios discussed there, we have added
* {{SECT:Tuning}}
* {{SECT:Troubleshooting}}
* {{SECT:Changes Since Previous Release}}
* {{SECT:Upgrading from 2.3.x}}
* {{SECT:Upgrading from 2.4.x}}
* {{SECT:Common errors encountered when using OpenLDAP Software}}
* {{SECT:Recommended OpenLDAP Software Dependency Versions}}
* {{SECT:Real World OpenLDAP Deployments and Examples}}
......@@ -36,164 +36,32 @@ asked on the OpenLDAP mailing lists and scenarios discussed there, we have added
Also, the table of contents is now 3 levels deep to ease navigation.
H2: New Features and Enhancements in 2.4
H2: New Features and Enhancements in 2.5
H3: Better {{B:cn=config}} functionality
There is a new slapd-config(5) manpage for the {{B:cn=config}} backend. The
original design called for auto-renaming of config entries when you insert or
delete entries with ordered names, but that was not implemented in 2.3. It is
now in 2.4. This means, e.g., if you have
> olcDatabase={1}mdb,cn=config
> olcSuffix: dc=example,dc=com
and you want to add a new subordinate, now you can ldapadd:
> olcDatabase={1}mdb,cn=config
> olcSuffix: dc=foo,dc=example,dc=com
This will insert a new back-mdb database in slot 1 and bump all following databases
down one, so the original back-mdb database will now be named:
> olcDatabase={2}mdb,cn=config
> olcSuffix: dc=example,dc=com
H3: Better {{B:cn=schema}} functionality
In 2.3 you were only able to add new schema elements, not delete or modify
existing elements. In 2.4 you can modify schema at will. (Except for the
hardcoded system schema, of course.)
H3: More sophisticated Syncrepl configurations
The original implementation of Syncrepl in OpenLDAP 2.2 was intended to support
multiple consumers within the same database, but that feature never worked and
was removed from OpenLDAP 2.3; you could only configure a single consumer in
any database.
In 2.4 you can configure multiple consumers in a single database. The configuration
possibilities here are quite complex and numerous. You can configure consumers
over arbitrary subtrees of a database (disjoint or overlapping). Any portion
of the database may in turn be provided to other consumers using the Syncprov
overlay. The Syncprov overlay works with any number of consumers over a single
database or over arbitrarily many glued databases.
H3: N-Way Multimaster Replication
As a consequence of the work to support multiple consumer contexts, the syncrepl
system now supports full N-Way multimaster replication with entry-level conflict
resolution. There are some important constraints, of course: In order to maintain
consistent results across all servers, you must maintain tightly synchronized
clocks across all participating servers (e.g., you must use NTP on all servers).
The entryCSNs used for replication now record timestamps with microsecond resolution,
instead of just seconds. The delta-syncrepl code has not been updated to support
multimaster usage yet, that will come later in the 2.4 cycle.
H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
Syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported
in 2.4; you can use syncrepl to replicate an entire server configuration from
one server to arbitrarily many other servers. It's possible to clone an entire
running slapd using just a small (less than 10 lines) seed configuration, or
you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test
suite provide working examples of these capabilities.
H3: Push-Mode Replication
In 2.3 you could configure syncrepl as a full push-mode replicator by using it
in conjunction with a back-ldap pointed at the target server. But because the
back-ldap database needs to have a suffix corresponding to the target's suffix,
you could only configure one instance per slapd.
In 2.4 you can define a database to be "hidden", which means that its suffix is
ignored when checking for name collisions, and the database will never be used
to answer requests received by the frontend. Using this "hidden" database feature
allows you to configure multiple databases with the same suffix, allowing you to
set up multiple back-ldap instances for pushing replication of a single database
to multiple targets. There may be other uses for hidden databases as well (e.g.,
using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem).
H3: More extensive TLS configuration control
In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For
outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came
from the system's ldap.conf file.
In 2.4 all of these sessions inherit their settings from the main slapd configuration,
but settings can be individually overridden on a per-config-item basis. This is
particularly helpful if you use certificate-based authentication and need to use a
different client certificate for different destinations.
H3: Performance enhancements
Too many to list. Some notable changes - ldapadd used to be a couple of orders
of magnitude slower than "slapadd -q". It's now at worst only about half the
speed of slapadd -q. Some comparisons of all the 2.x OpenLDAP releases are available
at {{URL:http://www.openldap.org/pub/hyc/scale2007.pdf}}
That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and CVS HEAD). Toward the latter end
of the "Cached Search Performance" chart it gets hard to see the difference
because the run times are so small, but the new code is about 25% faster than 2.3,
which was about 20% faster than 2.2, which was about 100% faster than 2.1, which
was about 100% faster than 2.0, in that particular search scenario. That test
basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache)
in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can
search over 500 thousand entries per second. The search was on an unindexed
attribute using a filter that would not match any entry, forcing slapd to examine
every entry in the DB, testing the filter for a match.
H3: New overlays
* slapo-constraint (Attribute value constraints)
* slapo-dds (Dynamic Directory Services, RFC 2589)
* slapo-memberof (reverse group membership maintenance)
H3: New features in existing Overlays
* slapo-pcache
- Inspection/Maintenance
-- the cache database can be directly accessed via
LDAP by adding a specific control to each LDAP request; a specific
extended operation allows to consistently remove cached entries and entire
cached queries
- Hot Restart
-- cached queries are saved on disk at shutdown, and reloaded if
not expired yet at subsequent restart
* slapo-rwm can safely interoperate with other overlays
* Dyngroup/Dynlist merge, plus security enhancements
- added dgIdentity support (draft-haripriya-dynamicgroup)
H3: New features in slapd
* monitoring of back-{b,h}db: cache fill-in, non-indexed searches,
* session tracking control (draft-wahl-ldap-session)
* subtree delete in back-sql (draft-armijo-ldap-treedelete)
* sorted values in multivalued attributes for faster matching
* lightweight dispatcher for greater throughput under heavy load and on
multiprocessor machines. (33% faster than 2.3 on AMD quad-socket dual-core server.)
H3: New features in libldap
* ldap_sync client API (LDAP Content Sync Operation, RFC 4533)
H3: New clients, tools and tool enhancements
* ldapexop for arbitrary extended operations
* Complete support of controls in request/response for all clients
* LDAP Client tools now honor SRV records
H3: New build options
* Support for building against GnuTLS
H2: Obsolete Features Removed From 2.5
These features were strongly deprecated in 2.4 and removed in 2.5.
......
......@@ -585,8 +585,8 @@ H3: `make test' fails
Some times, `make test' fails at the very first test with an obscure message like
> make test
> make[1]: Entering directory `/ldap_files/openldap-2.4.6/tests'
> make[2]: Entering directory `/ldap_files/openldap-2.4.6/tests'
> make[1]: Entering directory `/ldap_files/openldap-2.5.0/tests'
> make[2]: Entering directory `/ldap_files/openldap-2.5.0/tests'
> Initiating LDAP tests for MDB...
> Cleaning up test run directory leftover from previous run.
> Running ./scripts/all...
......@@ -607,9 +607,9 @@ Some times, `make test' fails at the very first test with an obscure message lik
> >>>>> Test failed
> >>>>> ./scripts/test000-rootdse failed (exit 1)
> make[2]: *** [mdb-yes] Error 1
> make[2]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
> make[2]: Leaving directory `/ldap_files/openldap-2.5.0/tests'
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
> make[1]: Leaving directory `/ldap_files/openldap-2.5.0/tests'
> make: *** [test] Error 2
or so. Usually, the five lines
......
......@@ -17,7 +17,6 @@ Feature|Software|Version
{{TERM[expand]TLS}}:
|{{PRD:OpenSSL}}|0.9.7+
|{{PRD:GnuTLS}}|2.12.0
|{{PRD:MozNSS}}|3.12.9
{{TERM[expand]SASL}}|{{PRD:Cyrus SASL}}|2.1.21+
{{TERM[expand]Kerberos}}:
|{{PRD:Heimdal}}|Version
......
......@@ -2,39 +2,15 @@
# Copyright 2007-2020 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Upgrading from 2.3.x
H1: Upgrading from 2.4.x
The following sections attempt to document the steps you will need to take in order
to upgrade from the latest 2.3.x OpenLDAP version.
to upgrade from the latest 2.4.x OpenLDAP version.
The normal upgrade procedure, as discussed in the {{SECT:Maintenance}} section, should
of course still be followed prior to doing any of this.
H2: {{B:cn=config}} olc* attributes
Quite a few {{olc*}} attributes have now become obsolete, if you see in your logs
entries like below, just remove them from the relevant ldif file.
> olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored)
H2: ACLs: searches require privileges on the search base
Search operations now require "search" privileges on the "entry" pseudo-attribute of the search
base. While upgrading from 2.3.x, make sure your ACLs grant such privileges to all desired search
bases.
For example, assuming you have the following ACL:
> access to dn.sub="ou=people,dc=example,dc=com" by * search
Searches using a base of "dc=example,dc=com" will only be allowed if you add the following ACL:
> access to dn.base="dc=example,dc=com" attrs=entry by * search
Note: The {{slapd.access}}(5) man page states that this requirement was introduced
with OpenLDAP 2.3. However, it is the default behavior only since 2.4.
ADD MORE HERE
......@@ -1017,7 +1017,6 @@ slapdconfigfile
modv
ObjectClassDescription
truelies
slurpd
basename
groupOfUniqueNames
DHAVE
......@@ -1351,9 +1350,6 @@ MChAODQ
lookups
GnuTLS
gnutls
MozNSS
MOZNSS
moznss
LTONLY
SNMP
timelimit
......
......@@ -63,16 +63,15 @@ installation instructions provided with it.
H3: {{TERM[expand]TLS}}
OpenLDAP clients and servers require installation of {{PRD:OpenSSL}},
{{PRD:GnuTLS}}, or {{PRD:MozNSS}}
OpenLDAP clients and servers require installation of {{PRD:OpenSSL}}
or {{PRD:GnuTLS}}
{{TERM:TLS}} libraries to provide {{TERM[expand]TLS}} services. Though
some operating systems may provide these libraries as part of the
base system or as an optional software component, OpenSSL, GnuTLS, and
Mozilla NSS often require separate installation.
base system or as an optional software component, OpenSSL and GnuTLS
often require separate installation.
OpenSSL is available from {{URL: http://www.openssl.org/}}.
GnuTLS is available from {{URL: http://www.gnu.org/software/gnutls/}}.
Mozilla NSS is available from {{URL: http://developer.mozilla.org/en/NSS}}.
OpenLDAP Software will not be fully LDAPv3 compliant unless OpenLDAP's
{{EX:configure}} detects a usable TLS library.
......
......@@ -383,8 +383,8 @@ SASL}} software which supports a number of mechanisms including
{{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
implementation can utilize {{PRD:OpenSSL}}, {{PRD:GnuTLS}},
or {{PRD:MozNSS}} software.
implementation can utilize {{PRD:OpenSSL}} or {{PRD:GnuTLS}},
software.
{{B:Topology control}}: {{slapd}} can be configured to restrict
access at the socket layer based upon network topology information.
......
......@@ -145,7 +145,7 @@ similar to:
> description: This object contains information about this server.
> description: Most of the information is held in operational attributes, which
> must be explicitly requested.
> monitoredInfo: OpenLDAP: slapd 2.4 (Dec 7 2006 17:30:29)
> monitoredInfo: OpenLDAP: slapd 2.5 (Dec 7 2006 17:30:29)
> entryDN: cn=Monitor
> subschemaSubentry: cn=Subschema
> hasSubordinates: TRUE
......
......@@ -623,7 +623,7 @@ specific database. For example, with the following minimal slapd.conf:
> suffix "dc=example,dc=com"
> rootdn "cn=Manager,dc=example,dc=com"
> rootpw secret
> directory /var/lib/ldap2.4
> directory /var/lib/ldap2.5
> checkpoint 256 5
> index objectClass eq
> index uid eq,sub
......
......@@ -443,43 +443,6 @@ and the syncrepl engine runs on the proxy.
For configuration, please see the {{SECT:Syncrepl Proxy}} section.
H4: Replacing Slurpd
The old {{slurpd}} mechanism only operated in provider-initiated
push mode. Slurpd replication was deprecated in favor of Syncrepl
replication and has been completely removed from OpenLDAP 2.4.
The slurpd daemon was the original replication mechanism inherited from
UMich's LDAP and operated in push mode: the master pushed changes to the
slaves. It was replaced for many reasons, in brief:
* It was not reliable
** It was extremely sensitive to the ordering of records in the replog
** It could easily go out of sync, at which point manual intervention was
required to resync the slave database with the master directory
** It wasn't very tolerant of unavailable servers. If a slave went down
for a long time, the replog could grow to a size that was too large for
slurpd to process
* It only worked in push mode
* It required stopping and restarting the master to add new slaves
* It only supported single master replication
Syncrepl has none of those weaknesses:
* Syncrepl is self-synchronizing; you can start with a consumer database
in any state from totally empty to fully synced and it will automatically
do the right thing to achieve and maintain synchronization
** It is completely insensitive to the order in which changes occur
** It guarantees convergence between the consumer and the provider
content without manual intervention
** It can resynchronize regardless of how long a consumer stays out
of contact with the provider
* Syncrepl can operate in either direction
* Consumers can be added at any time without touching anything on the
provider
* Multi-master replication is supported
H2: Configuring the different replication types
H3: Syncrepl
......
......@@ -19,7 +19,7 @@ identities. All servers are required to have valid certificates,
whereas client certificates are optional. Clients must have a
valid certificate in order to authenticate via SASL EXTERNAL.
For more information on creating and managing certificates,
see the {{PRD:OpenSSL}}, {{PRD:GnuTLS}}, or {{PRD:MozNSS}} documentation,
see the {{PRD:OpenSSL}} or {{PRD:GnuTLS}} documentation,
depending on which TLS implementation libraries you are using.
H3: Server Certificates
......@@ -90,37 +90,12 @@ this option can only be used with a filesystem that actually supports
symbolic links. In general, it is simpler to use the
{{EX:TLSCACertificateFile}} directive instead.
When using Mozilla NSS, this directive can be used to specify the
path of the directory containing the NSS certificate and key database
files. The {{certutil}} command can be used to add a {{TERM:CA}} certificate:
> certutil -d <path> -A -n "name of CA cert" -t CT,, -a -i /path/to/cacertfile.pem
. This command will add a CA certificate stored in the PEM (ASCII) formatted
. file named /path/to/cacertfile.pem. {{EX:-t CT,,}} means that the certificate is
. trusted to be a CA issuing certs for use in TLS clients and servers.
H4: TLSCertificateFile <filename>
This directive specifies the file that contains the slapd server
certificate. Certificates are generally public information and
require no special protection.
When using Mozilla NSS, if using a cert/key database (specified with
{{EX:TLSCACertificatePath}}), this directive specifies
the name of the certificate to use:
> TLSCertificateFile Server-Cert
. If using a token other than the internal built in token, specify the
. token name first, followed by a colon:
> TLSCertificateFile my hardware device:Server-Cert
. Use {{EX:certutil -L}} to list the certificates by name:
> certutil -d /path/to/certdbdir -L
H4: TLSCertificateKeyFile <filename>
This directive specifies the file that contains the private key
......@@ -130,18 +105,6 @@ password encrypted for protection. However, the current implementation
doesn't support encrypted keys so the key must not be encrypted
and the file itself must be protected carefully.
When using Mozilla NSS, this directive specifies the name of
a file that contains the password for the key for the certificate specified with
{{EX:TLSCertificateFile}}. The modutil command can be used to turn off password
protection for the cert/key database. For example, if {{EX:TLSCACertificatePath}}
specifies /etc/openldap/certdb as the location of the cert/key database, use
modutil to change the password to the empty string:
> modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
. You must have the old password, if any. Ignore the WARNING about the running
. browser. Press 'Enter' for the new password.
H4: TLSCipherSuite <cipher-suite-spec>
This directive configures what ciphers will be accepted and the
......@@ -161,13 +124,6 @@ To obtain the list of ciphers in GnuTLS use:
> gnutls-cli -l
When using Mozilla NSS, the OpenSSL cipher suite specifications are used and
translated into the format used internally by Mozilla NSS. There isn't an easy
way to list the cipher suites from the command line. The authoritative list
is in the source code for Mozilla NSS in the file sslinfo.c in the structure
> static const SSLCipherSuiteInfo suiteInfo[]
H4: TLSRandFile <filename>
This directive specifies the file to obtain random bits from when
......@@ -186,7 +142,7 @@ copy a few hundred bytes of arbitrary data into the file. The file
is only used to provide a seed for the pseudo-random number generator,
and it doesn't need very much data to work.
This directive is ignored with GnuTLS and Mozilla NSS.
This directive is ignored with GnuTLS.
H4: TLSDHParamFile <filename>
......@@ -201,8 +157,6 @@ generated using the following command
or
> certtool --generate-dh-params --bits <numbits> --outfile <filename>
This directive is ignored with Mozilla NSS.
H4: TLSECName <name>
This directive specifies the curve to use for Elliptic Curve
......@@ -212,7 +166,7 @@ curves may be shown using the following command
> openssl ecparam -list_curves
This directive is not used for GnuTLS and is ignored with Mozilla NSS.
This directive is not used for GnuTLS.
For GnuTLS the curves may be specified in the ciphersuite.
H4: TLSVerifyClient { never | allow | try | demand }
......@@ -273,7 +227,7 @@ H4: TLS_CACERTDIR <path>
This is equivalent to the server's {{EX:TLSCACertificatePath}} option. The
specified directory must be managed with the OpenSSL {{c_rehash}}
utility as well. If using Mozilla NSS, <path> may contain a cert/key database.
utility as well.
H4: TLS_CERT <filename>
......@@ -281,22 +235,6 @@ This directive specifies the file that contains the client certificate.
This is a user-only directive and can only be specified in a user's
{{.ldaprc}} file.
When using Mozilla NSS, if using a cert/key database (specified with
{{EX:TLS_CACERTDIR}}), this directive specifies
the name of the certificate to use:
> TLS_CERT Certificate for Sam Carter
. If using a token other than the internal built in token, specify the
. token name first, followed by a colon:
> TLS_CERT my hardware device:Certificate for Sam Carter
. Use {{EX:certutil -L}} to list the certificates by name:
> certutil -d /path/to/certdbdir -L
H4: TLS_KEY <filename>
This directive specifies the file that contains the private key
......
......@@ -6,14 +6,14 @@
# Preamble for all OpenLDAP SDF documents
#
!default VERSION 2.4
!default VERSION 2.5
#
# Paths are relative to the main subdirectories
#
!define DOC_AUTHOR "The OpenLDAP Project <{{URL:http://www.openldap.org/}}>"
!define DOC_NAME "OpenLDAP Software 2.4"
!define DOC_NAME "OpenLDAP Software 2.5"
!define DOC_TYPE "Guide"
!define DOC_LOGO "../images/LDAPlogo.gif"
......@@ -135,7 +135,6 @@ GnuTLS|http://www.gnu.org/software/gnutls/
Heimdal|http://www.pdc.kth.se/heimdal/
JLDAP|http://www.openldap.org/jldap/
MIT Kerberos|http://web.mit.edu/kerberos/www/
MozNSS|http://developer.mozilla.org/en/NSS
OpenLDAP|http://www.openldap.org/
OpenLDAP FAQ|http://www.openldap.org/faq/
OpenLDAP ITS|http://www.openldap.org/its/
......
......@@ -563,6 +563,22 @@ must be a
.BR "char **" .
Its content needs to be freed by the caller using
.BR ldap_memfree (3).
.B LDAP_OPT_X_SASL_CBINDING
Sets/gets the channel-binding type to use in SASL,
one of
.BR LDAP_OPT_X_SASL_CBINDING_NONE
(the default),
.BR LDAP_OPT_X_SASL_CBINDING_TLS_UNIQUE
the "tls-unique" type from RCF 5929.
.BR LDAP_OPT_X_SASL_CBINDING_TLS_ENDPOINT
the "tls-server-end-point" from RCF 5929, compatible with Windows.
.BR invalue
must be
.BR "const int *" ;
.BR outvalue
must be
.BR "int *" .
.TP
.SH TCP OPTIONS
The TCP options are OpenLDAP specific.
Mainly intended for use with Linux, they may not be portable.
......@@ -722,7 +738,6 @@ must be
.BR "char **" ,
and its contents need to be freed by the caller using
.BR ldap_memfree (3).
Ignored by Mozilla NSS.
.TP
.B LDAP_OPT_X_TLS_ECNAME
Gets/sets the name of the curve used for
......@@ -735,7 +750,7 @@ must be
.BR "char **" ,
and its contents need to be freed by the caller using
.BR ldap_memfree (3).
Ignored by GnuTLS and Mozilla NSS. In GnuTLS a curve may be selected
Ignored by GnuTLS. In GnuTLS a curve may be selected
in the cipher suite specification.
.TP
.B LDAP_OPT_X_TLS_KEYFILE
......@@ -789,7 +804,7 @@ must be
.BR "char **" ,
and its contents need to be freed by the caller using
.BR ldap_memfree (3).
Ignored by GnuTLS older than version 2.2. Ignored by Mozilla NSS.
Ignored by GnuTLS older than version 2.2.
.TP
.B LDAP_OPT_X_TLS_REQUIRE_CERT
Sets/gets the peer certificate checking strategy,
......
......@@ -286,6 +286,9 @@ size allowed. 0 disables security layers. The default is 65536.
.TP
.B SASL_NOCANON <on/true/yes/off/false/no>
Do not perform reverse DNS lookups to canonicalize SASL host names. The default is off.
.TP
.B SASL_CBINDING <none/tls-unique/tls-endpoint>
The channel-binding type to use, see also LDAP_OPT_X_SASL_CBINDING. The default is none.
.SH GSSAPI OPTIONS
If OpenLDAP is built with Generic Security Services Application Programming Interface support,
there are more options you can specify.
......@@ -320,30 +323,10 @@ certificates in separate individual files. The
is always used before
.B TLS_CACERTDIR.
This parameter is ignored with GnuTLS.
When using Mozilla NSS, <path> may contain a Mozilla NSS cert/key
database. If <path> contains a Mozilla NSS cert/key database and
CA cert files, OpenLDAP will use the cert/key database and will
ignore the CA cert files.
.TP
.B TLS_CERT <filename>
Specifies the file that contains the client certificate.
.B This is a user-only option.
When using Mozilla NSS, if using a cert/key database (specified with
TLS_CACERTDIR), TLS_CERT specifies the name of the certificate to use:
.nf
TLS_CERT Certificate for Sam Carter
.fi
If using a token other than the internal built in token, specify the
token name first, followed by a colon:
.nf
TLS_CERT my hardware device:Certificate for Sam Carter
.fi
Use certutil \-L to list the certificates by name:
.nf
certutil \-d /path/to/certdbdir \-L
.fi
.TP
.B TLS_KEY <filename>
Specifies the file that contains the private key that matches the certificate
......@@ -352,24 +335,11 @@ stored in the
file. Currently, the private key must not be protected with a password, so
it is of critical importance that the key file is protected carefully.
.B This is a user-only option.
When using Mozilla NSS, TLS_KEY specifies the name of a file that contains
the password for the key for the certificate specified with TLS_CERT. The
modutil command can be used to turn off password protection for the cert/key
database. For example, if TLS_CACERTDIR specifies /home/scarter/.moznss as
the location of the cert/key database, use modutil to change the password
to the empty string:
.nf
modutil \-dbdir ~/.moznss \-changepw 'NSS Certificate DB'
.fi
You must have the old password, if any. Ignore the WARNING about the running
browser. Press 'Enter' for the new password.
.TP
.B TLS_CIPHER_SUITE <cipher-suite-spec>
Specifies acceptable cipher suite and preference order.
<cipher-suite-spec> should be a cipher specification for
the TLS library in use (OpenSSL, GnuTLS, or Mozilla NSS).
the TLS library in use (OpenSSL or GnuTLS).
Example:
.RS
.RS
......@@ -399,14 +369,6 @@ In older versions of GnuTLS, where gnutls\-cli does not support the option
.nf
gnutls\-cli \-l
.fi
When using Mozilla NSS, the OpenSSL cipher suite specifications are used and
translated into the format used internally by Mozilla NSS. There isn't an easy
way to list the cipher suites from the command line. The authoritative list
is in the source code for Mozilla NSS in the file sslinfo.c in the structure
.nf
static const SSLCipherSuiteInfo suiteInfo[]
.fi
.RE
.TP
.B TLS_PROTOCOL_MIN <major>[.<minor>]
......@@ -430,7 +392,7 @@ This parameter is ignored with GnuTLS.
Specifies the file to obtain random bits from when /dev/[u]random is
not available. Generally set to the name of the EGD/PRNGD socket.
The environment variable RANDFILE can also be used to specify the filename.
This parameter is ignored with GnuTLS and Mozilla NSS.
This parameter is ignored with GnuTLS.
.TP
.B TLS_REQCERT <level>
Specifies what checks to perform on server certificates in a TLS session,
......@@ -463,7 +425,7 @@ Specifies if the Certificate Revocation List (CRL) of the CA should be
used to verify if the server certificates have not been revoked. This
requires
.B TLS_CACERTDIR
parameter to be set. This parameter is ignored with GnuTLS and Mozilla NSS.
parameter to be set. This parameter is ignored with GnuTLS.
.B <level>
can be specified as one of the following keywords:
.RS
......@@ -481,7 +443,7 @@ Check the CRL for a whole certificate chain
.B TLS_CRLFILE <filename>
Specifies the file containing a Certificate Revocation List to be used
to verify if the server certificates have not been revoked. This
parameter is only supported with GnuTLS and Mozilla NSS.
parameter is only supported with GnuTLS.
.SH "ENVIRONMENT VARIABLES"
.TP
LDAPNOINIT
......
......@@ -720,6 +720,10 @@ Used to specify the fully qualified domain name used for SASL processing.
.B olcSaslRealm: <realm>
Specify SASL realm. Default is empty.
.TP
.B olcSaslCbinding: none | tls-unique | tls-endpoint
Specify the channel-binding type, see also LDAP_OPT_X_SASL_CBINDING.
Default is none.
.TP
.B olcSaslSecProps: <properties>
Used to specify Cyrus SASL security properties.
The
......@@ -831,7 +835,7 @@ you can specify.
.B olcTLSCipherSuite: <cipher-suite-spec>
Permits configuring what ciphers will be accepted and the preference order.
<cipher-suite-spec> should be a cipher specification for
the TLS library in use (OpenSSL, GnuTLS, or Mozilla NSS).
the TLS library in use (OpenSSL or GnuTLS).
Example:
.RS
.RS
......@@ -861,14 +865,6 @@ In older versions of GnuTLS, where gnutls\-cli does not support the option
.nf
gnutls\-cli \-l
.fi
When using Mozilla NSS, the OpenSSL cipher suite specifications are used and
translated into the format used internally by Mozilla NSS. There isn't an easy
way to list the cipher suites from the command line. The authoritative list
is in the source code for Mozilla NSS in the file sslinfo.c in the structure
.nf
static const SSLCipherSuiteInfo suiteInfo[]
.fi
.RE
.TP
.B olcTLSCACertificateFile: <filename>
......@@ -883,32 +879,11 @@ certificates in separate individual files. Usually only one of this
or the olcTLSCACertificateFile is defined. If both are specified, both
locations will be used. This directive is not supported
when using GnuTLS.
When using Mozilla NSS, <path> may contain a Mozilla NSS cert/key
database. If <path> contains a Mozilla NSS cert/key database and
CA cert files, OpenLDAP will use the cert/key database and will
ignore the CA cert files.
.TP
.B olcTLSCertificateFile: <filename>
Specifies the file that contains the
.B slapd
server certificate.
When using Mozilla NSS, if using a cert/key database (specified with
olcTLSCACertificatePath), olcTLSCertificateFile specifies
the name of the certificate to use:
.nf
olcTLSCertificateFile: Server-Cert
.fi
If using a token other than the internal built in token, specify the
token name first, followed by a colon:
.nf
olcTLSCertificateFile: my hardware device:Server-Cert
.fi
Use certutil \-L to list the certificates by name:
.nf
certutil \-d /path/to/certdbdir \-L
.fi
.TP
.B olcTLSCertificateKeyFile: <filename>
Specifies the file that contains the
......@@ -920,19 +895,6 @@ be manually typed in when slapd starts. Usually the private key is not
protected with a password, to allow slapd to start without manual
intervention, so
it is of critical importance that the file is protected carefully.
When using Mozilla NSS, olcTLSCertificateKeyFile specifies the name of
a file that contains the password for the key for the certificate specified with
olcTLSCertificateFile. The modutil command can be used to turn off password
protection for the cert/key database. For example, if olcTLSCACertificatePath
specifies /etc/openldap/certdb as the location of the cert/key database, use
modutil to change the password to the empty string:
.nf
modutil \-dbdir /etc/openldap/certdb \-changepw 'NSS Certificate DB'
.fi
You must have the old password, if any. Ignore the WARNING about the running
browser. Press 'Enter' for the new password.
.TP
.B olcTLSDHParamFile: <filename>
This directive specifies the file that contains parameters for Diffie-Hellman
......@@ -945,15 +907,12 @@ actual client or server authentication and provide no protection against
man-in-the-middle attacks.
You should append "!ADH" to your cipher suites to ensure that these suites
are not used.
When using Mozilla NSS these parameters are always generated randomly
so this directive is ignored.
.TP
.B olcTLSECName: <name>
Specify the name of a curve to use for Elliptic curve Diffie-Hellman
ephemeral key exchange. This is required to enable ECDHE algorithms in
OpenSSL. This option is not used with GnuTLS; the curves may be
chosen in the GnuTLS ciphersuite specification. This option is also
ignored for Mozilla NSS.
chosen in the GnuTLS ciphersuite specification.
.TP
.B olcTLSProtocolMin: <major>[.<minor>]
Specifies minimum SSL/TLS protocol version that will be negotiated.
......@@ -976,7 +935,7 @@ This directive is ignored with GnuTLS.
Specifies the file to obtain random bits from when /dev/[u]random
is not available. Generally set to the name of the EGD/PRNGD socket.
The environment variable RANDFILE can also be used to specify the filename.
This directive is ignored with GnuTLS and Mozilla NSS.
This directive is ignored with GnuTLS.
.TP
.B olcTLSVerifyClient: <level>
Specifies what checks to perform on client certificates in an
......@@ -1018,7 +977,7 @@ Specifies if the Certificate Revocation List (CRL) of the CA should be
used to verify if the client certificates have not been revoked. This
requires
.B olcTLSCACertificatePath
parameter to be set. This parameter is ignored with GnuTLS and Mozilla NSS.
parameter to be set. This parameter is ignored with GnuTLS.
.B <level>
can be specified as one of the following keywords:
.RS
......@@ -1036,7 +995,7 @@ Check the CRL for a whole certificate chain
.B olcTLSCRLFile: <filename>
Specifies a file containing a Certificate Revocation List to be used
for verifying that certificates have not been revoked. This parameter
is only valid when using GnuTLS or Mozilla NSS.
is only valid when using GnuTLS.
.SH DYNAMIC MODULE OPTIONS
If
.B slapd
......
......@@ -914,6 +914,9 @@ The
property specifies the maximum security layer receive buffer
size allowed. 0 disables security layers. The default is 65536.
.TP
.B sasl\-cbinding none | tls-unique | tls-endpoint
Specify the channel-binding type, see also LDAP_OPT_X_SASL_CBINDING.
.TP
.B schemadn <dn>
Specify the distinguished name for the subschema subentry that
controls the entries on this server. The default is "cn=Subschema".
......@@ -1062,7 +1065,7 @@ you can specify.
.B TLSCipherSuite <cipher-suite-spec>
Permits configuring what ciphers will be accepted and the preference order.
<cipher-suite-spec> should be a cipher specification for the TLS library
in use (OpenSSL, GnuTLS, or Mozilla NSS).
in use (OpenSSL or GnuTLS).
Example:
.RS
.RS
......@@ -1092,14 +1095,6 @@ In older versions of GnuTLS, where gnutls\-cli does not support the option
.nf
gnutls\-cli \-l
.fi
When using Mozilla NSS, the OpenSSL cipher suite specifications are used and
translated into the format used internally by Mozilla NSS. There isn't an easy
way to list the cipher suites from the command line. The authoritative list
is in the source code for Mozilla NSS in the file sslinfo.c in the structure
.nf
static const SSLCipherSuiteInfo suiteInfo[]
.fi
.RE
.TP
.B TLSCACertificateFile <filename>
......@@ -1118,32 +1113,11 @@ Specifies the path of a directory that contains Certificate Authority
certificates in separate individual files. Usually only one of this
or the TLSCACertificateFile is used. This directive is not supported
when using GnuTLS.
When using Mozilla NSS, <path> may contain a Mozilla NSS cert/key
database. If <path> contains a Mozilla NSS cert/key database and
CA cert files, OpenLDAP will use the cert/key database and will
ignore the CA cert files.
.TP
.B TLSCertificateFile <filename>
Specifies the file that contains the
.B slapd
server certificate.
When using Mozilla NSS, if using a cert/key database (specified with
TLSCACertificatePath), TLSCertificateFile specifies
the name of the certificate to use:
.nf
TLSCertificateFile Server-Cert
.fi
If using a token other than the internal built in token, specify the
token name first, followed by a colon:
.nf
TLSCertificateFile my hardware device:Server-Cert
.fi
Use certutil \-L to list the certificates by name:
.nf
certutil \-d /path/to/certdbdir \-L
.fi
.TP
.B TLSCertificateKeyFile <filename>
Specifies the file that contains the
......@@ -1152,18 +1126,6 @@ server private key that matches the certificate stored in the
.B TLSCertificateFile
file. Currently, the private key must not be protected with a password, so
it is of critical importance that it is protected carefully.
When using Mozilla NSS, TLSCertificateKeyFile specifies the name of
a file that contains the password for the key for the certificate specified with
TLSCertificateFile. The modutil command can be used to turn off password
protection for the cert/key database. For example, if TLSCACertificatePath
specifies /etc/openldap/certdb as the location of the cert/key database, use
modutil to change the password to the empty string:
.nf
modutil \-dbdir /etc/openldap/certdb \-changepw 'NSS Certificate DB'
.fi
You must have the old password, if any. Ignore the WARNING about the running
browser. Press 'Enter' for the new password.
.TP
.B TLSDHParamFile <filename>
This directive specifies the file that contains parameters for Diffie-Hellman
......@@ -1176,15 +1138,12 @@ actual client or server authentication and provide no protection against
man-in-the-middle attacks.
You should append "!ADH" to your cipher suites to ensure that these suites
are not used.
When using Mozilla NSS these parameters are always generated randomly
so this directive is ignored.
.TP
.B TLSECName <name>
Specify the name of a curve to use for Elliptic curve Diffie-Hellman
ephemeral key exchange. This is required to enable ECDHE algorithms in
OpenSSL. This option is not used with GnuTLS; the curves may be
chosen in the GnuTLS ciphersuite specification. This option is also
ignored for Mozilla NSS.
chosen in the GnuTLS ciphersuite specification.
.TP
.B TLSProtocolMin <major>[.<minor>]
Specifies minimum SSL/TLS protocol version that will be negotiated.
......@@ -1207,7 +1166,7 @@ This directive is ignored with GnuTLS.
Specifies the file to obtain random bits from when /dev/[u]random
is not available. Generally set to the name of the EGD/PRNGD socket.
The environment variable RANDFILE can also be used to specify the filename.
This directive is ignored with GnuTLS and Mozilla NSS.
This directive is ignored with GnuTLS.
.TP
.B TLSVerifyClient <level>
Specifies what checks to perform on client certificates in an
......@@ -1249,7 +1208,7 @@ Specifies if the Certificate Revocation List (CRL) of the CA should be
used to verify if the client certificates have not been revoked. This
requires
.B TLSCACertificatePath
parameter to be set. This directive is ignored with GnuTLS and Mozilla NSS.
parameter to be set. This directive is ignored with GnuTLS.
.B <level>
can be specified as one of the following keywords:
.RS
......@@ -1267,7 +1226,7 @@ Check the CRL for a whole certificate chain
.B TLSCRLFile <filename>
Specifies a file containing a Certificate Revocation List to be used
for verifying that certificates have not been revoked. This directive is
only valid when using GnuTLS and Mozilla NSS.
only valid when using GnuTLS.
.SH GENERAL BACKEND OPTIONS
Options in this section only apply to the configuration file section
for the specified backend. They are supported by every
......