mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
156 lines
5.8 KiB
Plaintext
156 lines
5.8 KiB
Plaintext
# Copyright 1999-2001, The OpenLDAP Foundation, All Rights Reserved.
|
|
# 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
|
|
Internet. Hence, OpenLDAP Software provides many different security
|
|
mechanisms. This chapter describes these mechanisms and discusses
|
|
security considerations for using OpenLDAP Software.
|
|
|
|
H2: Network Security
|
|
|
|
H3: Selective Listening
|
|
|
|
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
|
|
{{EX:127.0.0.1}} will disallow remote access to the directory server.
|
|
E.g.:
|
|
|
|
> slapd -h ldap://127.0.0.1
|
|
|
|
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
|
|
restrict remote access, it is recommend that an IP Firewall be
|
|
used to restrict access.
|
|
|
|
See {{SECT:Command-line Options}} and {{slapd}}(8) for more
|
|
information.
|
|
|
|
|
|
H3: IP Firewall
|
|
|
|
{{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.
|
|
|
|
Generally, {{slapd}}(8) listens on port 389/tcp for LDAP over
|
|
{{TERM:TCP}} (e.g. {{F:ldap://}}) and port 636/tcp for LDAP over
|
|
{{TERM:SSL}} (e.g. {{F:ldaps://}}).
|
|
|
|
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
|
|
|
|
OpenLDAP 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:
|
|
|
|
> slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
|
|
> slapd: ALL : DENY
|
|
|
|
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.
|
|
|
|
It is noted that TCP wrappers require the connection to be accepted.
|
|
As significant processing is required just to deny a connection,
|
|
it is generally advised that IP firewall protection be used instead
|
|
of TCP wrappers.
|
|
|
|
See {{hosts_access}}(5) for more information on TCP wrapper rules.
|
|
|
|
|
|
H2: Integrity and Confidentiality Protection
|
|
|
|
{{TERM[expand]TLS}} (TLS) can be used to provide integrity and
|
|
confidentiality protection. OpenLDAP supports both StartTLS and
|
|
{{F:ldaps://}}. See the {{SECT:Using TLS}} chapter for more
|
|
information.
|
|
|
|
A number of {{TERM[expand]SASL}} (SASL) mechanisms, such as DIGEST-MD5
|
|
and {{TERM:GSSAPI}}, also provide integrity and confidentiality
|
|
protection. See the {{SECT:Using SASL}} chapter for more information.
|
|
|
|
|
|
H3: Security Strength Factors
|
|
|
|
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.
|
|
|
|
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
|
|
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.
|
|
|
|
An anonymous bind results in an {{anonymous}} authorization.
|
|
Anonymous bind mechanism is enabled by default, but can be disabled
|
|
by specifying "{{EX:disallow bind_anon}}" in {{slapd.conf}}(5).
|
|
|
|
An unauthenticated bind results in an {{anonymous}} authorization.
|
|
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 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}}".
|
|
|
|
Note: An unsuccessful bind always results in the session having
|
|
an {{anonymous}} authorization state.
|
|
|
|
|
|
H3: SASL method
|
|
|
|
The LDAP SASL method allows use of any SASL authentication
|
|
mechanism. The {{SECT:Using SASL}} discusses use of SASL.
|
|
|