and {{superior}} knowledge information.
!else
{{slapd}} supports {{subordinate}} and {{superior}} knowledge information.
+Subordinate knowledge information is held in {{EX:referral}}
+objects ({{REF:RFC3296}}).
!endif
H2: Superior Knowledge Information
-Superior knowledge information may be specified using the
-{{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 a directory service with
-{{global knowledge}}, such as the {{OpenLDAP Root Service}}
+Superior knowledge information may be specified using the {{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 a directory service with {{global knowledge}},
+such as the {{OpenLDAP Root Service}}
({{URL:http://www.openldap.org/faq/index.cgi?file=393}}).
> referral ldap://root.openldap.org/
SASL in OpenLDAP.
There are several industry standard authentication mechanisms that
-can be used with SASL, including Kerberos V4, GSSAPI, and some of
-the Digest mechanisms. The standard client tools provided with
-OpenLDAP, such as {{ldapsearch}}(1) and {{ldapmodify}}(1), will by
-default attempt to authenticate the user to the {{slapd}}(8) server
-using SASL. Basic authentication service can be set up by the LDAP
+can be used with SASL, including {{TERM:Kerberos}} V4, {{TERM:GSSAPI}},
+and DIGEST-MD. The standard client tools provided with OpenLDAP,
+such as {{ldapsearch}}(1) and {{ldapmodify}}(1), will by default
+attempt to authenticate the user to the {{slapd}}(8) server using
+SASL. Basic authentication service can be set up by the LDAP
administrator with a few steps, allowing users to be authenticated
to the slapd server as their LDAP entry. With a few extra steps,
some users and services can be allowed to exploit SASL's proxy
This chapter assumes you have read {{Cyrus SASL for System
Administrators}}, provided with the {{PRD:Cyrus}} {{PRD:SASL}}
-package (in {{FILE:doc/sysadmin.html}}).
+package (in {{FILE:doc/sysadmin.html}}) and have a working Cyrus
+SASL installation. You should use the Cyrus SASL {{EX:sample_client}}
+and {{EX:sample_server}} to test your SASL installation before
+attempting to make use of it in OpenLDAP.
Note that in the following text the term {{user}} is used to describe
a person or application entity who is connecting to the LDAP server
The EXTERNAL mechanism utilizes authentication services provided
by lower level network services such as {{TERM:TLS}} (TLS). When
-used in conjunction with TLS {{TERM:X.509}}-based public key technology,
-EXTERNAL offers strong authentication. Use of EXTERNAL is discussed
-in the {{SECT:Using TLS}} chapter.
+used in conjunction with {{TERM:TLS}} {{TERM:X.509}}-based public
+key technology, EXTERNAL offers strong authentication. Use of
+EXTERNAL is discussed in the {{SECT:Using TLS}} chapter.
There are other strong authentication mechanisms to choose from,
including OTP (one time passwords) and SRP (secure remote passwords).
H3: GSSAPI
This section describes the use of the SASL GSSAPI mechanism and
-Kerberos V with OpenLDAP. Since Kerberos V is being used, the information
-is very similar to the previous section.
-It will be assumed that you have Kerberos
-V deployed, you are familiar with the operation of the system, and that
-your users are trained in its use. This section also assumes you have
-familiarized yourself with the use of the GSSAPI mechanism by reading
-{{Configuring GSSAPI and Cyrus SASL}} (provided with Cyrus SASL in
-the {{FILE:doc/gssapi}} file) and successfully experimented with
-the Cyrus provided sample_server and sample_client applications.
-General information about Kerberos is available at
+Kerberos V with OpenLDAP. Since Kerberos V is being used, the
+information is very similar to the previous section. It will be
+assumed that you have Kerberos V deployed, you are familiar with
+the operation of the system, and that your users are trained in its
+use. This section also assumes you have familiarized yourself with
+the use of the GSSAPI mechanism by reading {{Configuring GSSAPI and
+Cyrus SASL}} (provided with Cyrus SASL in the {{FILE:doc/gssapi}}
+file) and successfully experimented with the Cyrus provided
+{{EX:sample_server}} and {{EX:sample_client}} applications. General
+information about Kerberos is available at
{{URL:http://web.mit.edu/kerberos/www/}}.
To use the GSSAPI mechanism with {{slapd}}(8) one must create a service
will not be available, and the command names will not have the trailing
digit "2".
-To use secrets stored in {{sasldb,}} simply add users with the
+To use secrets stored in {{sasldb}}, simply add users with the
{{saslpasswd2}} command:
> saslpasswd2 -c <username>
> ldapsearch -Y DIGEST-MD5 -U u000997 -b dc=example,dc=com 'cn=andrew*'
-Note: in each of the above cases, no authorization identity (e.g. {{EX:-X}})
-was provided. Unless you are attempting {{SECT:SASL Proxy
-Authorization}}, no authorization identity should be specified.
-The server will infer an authorization identity from authentication
-identity (as described below).
+Note: in each of the above cases, no authorization identity (e.g.
+{{EX:-X}}) was provided. Unless you are attempting
+{{SECT:SASL Proxy Authorization}}, no authorization identity should
+be specified. The server will infer an authorization identity from
+authentication identity (as described below).
H3: Mapping Authentication identities to LDAP entries
Also note that the values in an authorization rule must be one of
the two forms: an LDAP URL or a DN (with or without regular expression
-characters). Anything that does not begin with "ldap://" is taken
-as a DN. It is not permissable to enter another authorization
-identity of the form "u:<username>" as an authorization rule.
+characters). Anything that does not begin with "{{EX:ldap://}}" is
+taken as a DN. It is not permissable to enter another authorization
+identity of the form "{{EX:u:<username>}}" as an authorization rule.
H4: Policy Configuration
do not ensure a password was provided), this mechanism should
generally not be enabled.
-A successful authenticated bind results in a user authorization
-identity, the provided name, being associated with the session.
-Authenticated bind is enabled by default. However, as this mechanism
-offers no evesdropping protection (e.g., the password is set in the
-clear), it is generally recommended that it be used only in tightly
-controlled systems or when the LDAP session is protected by other
-means (e.g., TLS, {{TERM:IPSEC}}). Where the administrator relies
-on TLS to protect the password, it is recommended that unprotected
-authentication be disabled. This is done by setting "{{EX:disallow
-bind_simple_unprotected}} in {{slapd.conf}}(5). The authenticated
-bind mechanism can be completely disabled by setting "{{EX:disallow
-bind_simple}}".
+A successful user/password authenticated bind results in a user
+authorization identity, the provided name, being associated with
+the session. User/password authenticated bind is enabled by default.
+However, as this mechanism offers no evesdropping protection (e.g.,
+the password is set in the clear), it is recommended that it be
+used only in tightly controlled systems or when the LDAP session
+is protected by other means (e.g., TLS, {{TERM:IPSEC}}). Where the
+administrator relies on TLS to protect the password, it is recommended
+that unprotected authentication be disabled. This is done by setting
+"{{EX:disallow bind_simple_unprotected}} in {{slapd.conf}}(5). The
+user/password authenticated bind mechanism can be completely disabled
+by setting "{{EX:disallow bind_simple}}".
Note: An unsuccessful bind always results in the session having
an {{anonymous}} authorization state.
projects / openldap / commitdiff