]> git.sur5r.net Git - openldap/blobdiff - doc/guide/admin/security.sdf
Clean up syntaxes and matching rules
[openldap] / doc / guide / admin / security.sdf
index 2f9360e5eae7b7d86daa29ae5afec4479040072e..554a9f39d6d134f3d0801c8ccd97b43f9bb3e961 100644 (file)
@@ -1,4 +1,4 @@
-# Copyright 1999-2001, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved.
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 
 H1: Security Considerations
@@ -6,6 +6,159 @@ 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 discusses security considerations for
-using OpenLDAP Software.
+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 {{SECT: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://}}).  Note that LDAP over TCP
+sessions can be protected by {{TERM:TLS}} through the use of
+{{StartTLS}}.  StartTLS is the Standard Track mechanism for protecting
+LDAP sessions with TLS.
+
+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.
+Note that IP addresses are used as {{slapd}}(8) is not normally
+configured to perform reverse lookups.
+
+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 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 {{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.
+
+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.
+
+
+H3: SASL method
+
+The LDAP SASL method allows use of any SASL authentication
+mechanism.  The {{SECT:Using SASL}} discusses use of SASL.