2006-01-04 07:11:52 +08:00
|
|
|
# Copyright 1999-2006 The OpenLDAP Foundation, All Rights Reserved.
|
2002-06-18 08:11:36 +08:00
|
|
|
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
|
|
|
|
|
|
|
H1: Security Considerations
|
|
|
|
|
|
|
|
OpenLDAP Software is designed to run in a wide variety of computing
|
|
|
|
environments from tightly-controlled closed networks to the global
|
2005-03-26 15:12:55 +08:00
|
|
|
Internet. Hence, OpenLDAP Software supports many different security
|
2002-06-18 08:55:39 +08:00
|
|
|
mechanisms. This chapter describes these mechanisms and discusses
|
|
|
|
security considerations for using OpenLDAP Software.
|
2002-06-18 08:11:36 +08:00
|
|
|
|
2002-06-18 08:55:39 +08:00
|
|
|
H2: Network Security
|
|
|
|
|
2002-06-18 15:11:58 +08:00
|
|
|
H3: Selective Listening
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
By default, {{slapd}}(8) will listen on both the IPv4 and IPv6 "any"
|
|
|
|
addresses. It is often desirable to have {{slapd}} listen on select
|
|
|
|
address/port pairs. For example, listening only on the IPv4 address
|
2002-06-18 15:11:58 +08:00
|
|
|
{{EX:127.0.0.1}} will disallow remote access to the directory server.
|
|
|
|
E.g.:
|
|
|
|
|
|
|
|
> slapd -h ldap://127.0.0.1
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
While the server can be configured to listen on a particular interface
|
|
|
|
address, this doesn't necessarily restrict access to the server to
|
|
|
|
only those networks accessible via that interface. To selective
|
2002-08-27 06:10:32 +08:00
|
|
|
restrict remote access, it is recommend that an {{SECT:IP Firewall}}
|
|
|
|
be used to restrict access.
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
See {{SECT:Command-line Options}} and {{slapd}}(8) for more
|
|
|
|
information.
|
|
|
|
|
|
|
|
|
|
|
|
H3: IP Firewall
|
|
|
|
|
2002-06-18 15:11:58 +08:00
|
|
|
{{TERM:IP}} firewall capabilities of the server system can be used
|
|
|
|
to restrict access based upon the client's IP address and/or network
|
|
|
|
interface used to communicate with the client.
|
2002-06-18 08:55:39 +08:00
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
Generally, {{slapd}}(8) listens on port 389/tcp for {{F:ldap://}}
|
|
|
|
sessions and port 636/tcp for {{F:ldaps://}}) sessions. {{slapd}}(8)
|
|
|
|
may be configured to listen on other ports.
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
As specifics of how to configure IP firewall are dependent on the
|
|
|
|
particular kind of IP firewall used, no examples are provided here.
|
|
|
|
See the document associated with your IP firewall.
|
|
|
|
|
|
|
|
|
|
|
|
H3: TCP Wrappers
|
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
{{slapd}}(8) supports {{TERM:TCP}} Wrappers. TCP Wrappers provide
|
|
|
|
a rule-based access control system for controlling TCP/IP access
|
|
|
|
to the server. For example, the {{host_options}}(5) rule:
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
> slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
|
|
|
|
> slapd: ALL : DENY
|
|
|
|
|
2002-06-18 15:11:58 +08:00
|
|
|
allows only incoming connections from the private network {{F:10.0.0.0}}
|
|
|
|
and localhost ({{F:127.0.0.1}}) to access the directory service.
|
2002-08-27 06:10:32 +08:00
|
|
|
Note that IP addresses are used as {{slapd}}(8) is not normally
|
|
|
|
configured to perform reverse lookups.
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
It is noted that TCP wrappers require the connection to be accepted.
|
|
|
|
As significant processing is required just to deny a connection,
|
2002-06-18 15:11:58 +08:00
|
|
|
it is generally advised that IP firewall protection be used instead
|
|
|
|
of TCP wrappers.
|
2002-06-18 08:55:39 +08:00
|
|
|
|
|
|
|
See {{hosts_access}}(5) for more information on TCP wrapper rules.
|
2002-06-18 15:11:58 +08:00
|
|
|
|
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
H2: Data Integrity and Confidentiality Protection
|
2002-06-18 15:11:58 +08:00
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
{{TERM[expand]TLS}} (TLS) can be used to provide data integrity and
|
|
|
|
confidentiality protection. OpenLDAP supports negotiation of
|
|
|
|
{{TERM:TLS}} ({{TERM:SSL}}) via both StartTLS and {{F:ldaps://}}.
|
|
|
|
See the {{SECT:Using TLS}} chapter for more information. StartTLS
|
|
|
|
is the standard track mechanism.
|
2002-06-18 15:11:58 +08:00
|
|
|
|
|
|
|
A number of {{TERM[expand]SASL}} (SASL) mechanisms, such as DIGEST-MD5
|
2005-03-26 15:12:55 +08:00
|
|
|
and {{TERM:GSSAPI}}, also provide data integrity and confidentiality
|
2002-06-19 09:39:26 +08:00
|
|
|
protection. See the {{SECT:Using SASL}} chapter for more information.
|
2002-06-18 15:11:58 +08:00
|
|
|
|
2002-06-18 15:41:56 +08:00
|
|
|
|
|
|
|
H3: Security Strength Factors
|
|
|
|
|
2002-06-18 16:02:36 +08:00
|
|
|
The server uses {{TERM[expand]SSF}}s (SSF) to indicate the relative
|
|
|
|
strength of protection. A SSF of zero (0) indicates no protections
|
|
|
|
are in place. A SSF of one (1) indicates integrity protection are
|
|
|
|
in place. A SSF greater than one (>1) roughly correlates to the
|
|
|
|
effective encryption key length. For example, {{TERM:DES}} is 56,
|
|
|
|
{{TERM:3DES}} is 112, and {{TERM:AES}} 128, 192, or 256.
|
2002-06-18 15:41:56 +08:00
|
|
|
|
|
|
|
A number of administrative controls rely on SSFs associated with
|
|
|
|
TLS and SASL protection in place on an LDAP session.
|
|
|
|
|
|
|
|
{{EX:security}} controls disallow operations when appropriate
|
|
|
|
protections are not in place. For example:
|
|
|
|
|
|
|
|
> security ssf=1 update_ssf=112
|
|
|
|
|
|
|
|
requires integrity protection for all operations and encryption
|
2002-06-19 09:39:26 +08:00
|
|
|
protection, 3DES equivalent, for update operations (e.g. add, delete,
|
|
|
|
modify, etc.). See {{slapd.conf}}(5) for details.
|
|
|
|
|
|
|
|
For fine-grained control, SSFs may be used in access controls. See
|
|
|
|
{{SECT:Access Control}} section of the {{SECT:The slapd Configuration
|
|
|
|
File}} for more information.
|
|
|
|
|
|
|
|
|
|
|
|
H2: Authentication Methods
|
|
|
|
|
|
|
|
H3: "simple" method
|
|
|
|
|
|
|
|
The LDAP "simple" method has three modes of operation:
|
|
|
|
|
|
|
|
* anonymous,
|
|
|
|
* unauthenticated, and
|
|
|
|
* user/password authenticated.
|
|
|
|
|
|
|
|
Anonymous access is obtained by providing no name and no password
|
|
|
|
to the "simple" bind operation. Unauthenticated access is obtained
|
|
|
|
by providing a name but no password. Authenticated access is obtain
|
|
|
|
by providing a valid name and password.
|
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
An anonymous bind results in an {{anonymous}} authorization
|
|
|
|
association. Anonymous bind mechanism is enabled by default, but
|
|
|
|
can be disabled by specifying "{{EX:disallow bind_anon}}" in
|
2006-05-17 02:40:07 +08:00
|
|
|
{{slapd.conf}}(5). Note that disabling the anonymous bind mechanism
|
|
|
|
does not prevent anonymous access to the directory. To require
|
|
|
|
authentication to access the directory, one should instead
|
|
|
|
specify "{{EX:require authc}}".
|
2002-06-19 09:39:26 +08:00
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
An unauthenticated bind also results in an {{anonymous}} authorization
|
|
|
|
association. Unauthenticated bind mechanism is disabled by default,
|
|
|
|
but can be enabled by specifying "{{EX:allow bind_anon_cred}}" in
|
|
|
|
{{slapd.conf}}(5). As a number of LDAP applications mistakenly
|
|
|
|
generate unauthenticated bind request when authenticated access was
|
|
|
|
intended (that is, they do not ensure a password was provided),
|
|
|
|
this mechanism should generally remain disabled.
|
2002-06-19 09:39:26 +08:00
|
|
|
|
2002-08-29 12:56:05 +08:00
|
|
|
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.
|
2005-03-26 15:12:55 +08:00
|
|
|
However, as this mechanism itself 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 {{EX:security}} directive's {{EX:simple_bind}}
|
|
|
|
option provides fine grain control over the level of confidential
|
|
|
|
protection to require for {{simple}} user/password authentication.
|
2002-10-08 09:07:12 +08:00
|
|
|
|
2002-10-05 03:08:10 +08:00
|
|
|
The user/password authenticated bind mechanism can be completely
|
|
|
|
disabled by setting "{{EX:disallow bind_simple}}".
|
2002-06-19 09:39:26 +08:00
|
|
|
|
|
|
|
Note: An unsuccessful bind always results in the session having
|
2005-03-26 15:12:55 +08:00
|
|
|
an {{anonymous}} authorization association.
|
2002-06-19 09:39:26 +08:00
|
|
|
|
|
|
|
|
|
|
|
H3: SASL method
|
2002-06-18 15:41:56 +08:00
|
|
|
|
2005-03-26 15:12:55 +08:00
|
|
|
The LDAP {{TERM:SASL}} method allows use of any SASL authentication
|
2002-06-19 09:39:26 +08:00
|
|
|
mechanism. The {{SECT:Using SASL}} discusses use of SASL.
|
2002-06-18 15:11:58 +08:00
|
|
|
|