Misc updates...

This commit is contained in:
Kurt Zeilenga 2002-08-29 04:56:05 +00:00
parent 02ec62a9ed
commit 20ef1d9fe4
5 changed files with 55 additions and 48 deletions

View File

@ -168,13 +168,13 @@ in the {{slapd.conf}}(5) manual page and the
{{SECT:The slapd Configuration File}} chapter of this
document.
Note: the directory specified must exist prior to starting slapd(8).
Note: the directory specified must exist prior to starting {{slapd}}(8).
.{{S: }}
+{{B:Start SLAPD}}.
. You are now ready to start the stand-alone LDAP server, slapd(8),
. You are now ready to start the stand-alone LDAP server, {{slapd}}(8),
by running the command:
..{{EX:su root -c /usr/local/libexec/slapd}}

View File

@ -14,6 +14,8 @@ certain part of the tree (which may or may not be running {{slapd}}).
and {{superior}} knowledge information.
!else
{{slapd}} supports {{subordinate}} and {{superior}} knowledge information.
Subordinate knowledge information is held in {{EX:referral}}
objects ({{REF:RFC3296}}).
!endif
@ -81,12 +83,12 @@ is similar to an X.500 knowledge reference held in a
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/

View File

@ -9,11 +9,11 @@ in {{REF:RFC2222}}. This chapter describes how to make use of
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
@ -22,7 +22,10 @@ then switch their identity to that of another user or service.
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
@ -65,9 +68,9 @@ and {{SECT:GSSAPI}} are discussed below.
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).
@ -156,16 +159,16 @@ request DN would not appear.
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
@ -229,7 +232,7 @@ of Cyrus SASL 2.1. If you are using version 1.5 then certain features
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>
@ -287,11 +290,11 @@ necessary to specify which one to use, e.g.:
> 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
@ -661,9 +664,9 @@ comparison can be evaluated much faster than an LDAP search for
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

View File

@ -136,18 +136,18 @@ bind request when authenticated access was intended (that is, they
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.

View File

@ -216,4 +216,6 @@ RFC2829|PS|Authentication Methods for LDAP|ftp://ftp.isi.edu/in-notes/rfc2829.tx
RFC2830|PS|LDAPv3: Extension for Transport Layer Security|ftp://ftp.isi.edu/in-notes/rfc2830.txt
RFC2831|PS|Using Digest Authentication as a SASL Mechanism|ftp://ftp.isi.edu/in-notes/rfc2831.txt
RFC2849|PS|The LDAP Data Interchange Format|ftp://ftp.isi.edu/in-notes/rfc2849.txt
RFC3088|X|OpenLDAP Root Service|ftp://ftp.isi.edu/in-notes/rfc3088.txt
RFC3296|PS|Named Subordinate References in LDAP|ftp://ftp.isi.edu/in-notes/rfc3296.txt
!endblock