git.sur5r.net Git - openldap/blob - doc/guide/admin/security.sdf

   1 # Copyright 1999-2005, The OpenLDAP Foundation, All Rights Reserved.
   2 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
   3
   4 H1: Security Considerations
   5
   6 OpenLDAP Software is designed to run in a wide variety of computing
   7 environments from tightly-controlled closed networks to the global
   8 Internet.  Hence, OpenLDAP Software provides many different security
   9 mechanisms.  This chapter describes these mechanisms and discusses
  10 security considerations for using OpenLDAP Software.
  11
  12 H2: Network Security
  13
  14 H3: Selective Listening
  15
  16 By default, {{slapd}}(8) will listen on both the IPv4 and IPv6 "any"
  17 addresses.  It is often desirable to have {{slapd}} listen on select
  18 address/port pairs.  For example, listening only on the IPv4 address
  19 {{EX:127.0.0.1}} will disallow remote access to the directory server.
  20 E.g.:
  21
  22 >       slapd -h ldap://127.0.0.1
  23
  24 While the server can be configured to listen on a particular interface
  25 address, this doesn't necessarily restrict access to the server to
  26 only those networks accessible via that interface.   To selective
  27 restrict remote access, it is recommend that an {{SECT:IP Firewall}}
  28 be used to restrict access.
  29
  30 See {{SECT:Command-line Options}} and {{slapd}}(8) for more
  31 information.
  32
  33
  34 H3: IP Firewall
  35
  36 {{TERM:IP}} firewall capabilities of the server system can be used
  37 to restrict access based upon the client's IP address and/or network
  38 interface used to communicate with the client.
  39
  40 Generally, {{slapd}}(8) listens on port 389/tcp for LDAP over
  41 {{TERM:TCP}} (e.g.  {{F:ldap://}}) and port 636/tcp for LDAP over
  42 {{TERM:SSL}} (e.g.  {{F:ldaps://}}).  Note that LDAP over TCP
  43 sessions can be protected by {{TERM:TLS}} through the use of
  44 {{StartTLS}}.  StartTLS is the Standard Track mechanism for protecting
  45 LDAP sessions with TLS.
  46
  47 As specifics of how to configure IP firewall are dependent on the
  48 particular kind of IP firewall used, no examples are provided here.
  49 See the document associated with your IP firewall.
  50
  51
  52 H3: TCP Wrappers
  53
  54 OpenLDAP supports {{TERM:TCP}} Wrappers.  TCP Wrappers provide a rule-based
  55 access control system for controlling TCP/IP access to the server.
  56 For example, the {{host_options}}(5) rule:
  57
  58 >       slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
  59 >       slapd: ALL : DENY
  60
  61 allows only incoming connections from the private network {{F:10.0.0.0}}
  62 and localhost ({{F:127.0.0.1}}) to access the directory service.
  63 Note that IP addresses are used as {{slapd}}(8) is not normally
  64 configured to perform reverse lookups.
  65
  66 It is noted that TCP wrappers require the connection to be accepted.
  67 As significant processing is required just to deny a connection,
  68 it is generally advised that IP firewall protection be used instead
  69 of TCP wrappers.
  70
  71 See {{hosts_access}}(5) for more information on TCP wrapper rules.
  72
  73
  74 H2: Integrity and Confidentiality Protection
  75
  76 {{TERM[expand]TLS}} (TLS) can be used to provide integrity and
  77 confidentiality protection.  OpenLDAP supports both StartTLS and
  78 {{F:ldaps://}}.  See the {{SECT:Using TLS}} chapter for more
  79 information.
  80
  81 A number of {{TERM[expand]SASL}} (SASL) mechanisms, such as DIGEST-MD5
  82 and {{TERM:GSSAPI}}, also provide integrity and confidentiality
  83 protection.  See the {{SECT:Using SASL}} chapter for more information.
  84
  85
  86 H3: Security Strength Factors
  87
  88 The server uses {{TERM[expand]SSF}}s (SSF) to indicate the relative
  89 strength of protection.  A SSF of zero (0) indicates no protections
  90 are in place.  A SSF of one (1) indicates integrity protection are
  91 in place.  A SSF greater than one (>1) roughly correlates to the
  92 effective encryption key length.  For example, {{TERM:DES}} is 56,
  93 {{TERM:3DES}} is 112, and {{TERM:AES}} 128, 192, or 256.
  94
  95 A number of administrative controls rely on SSFs associated with
  96 TLS and SASL protection in place on an LDAP session.
  97
  98 {{EX:security}} controls disallow operations when appropriate
  99 protections are not in place.  For example:
 100
 101 >       security ssf=1 update_ssf=112
 102
 103 requires integrity protection for all operations and encryption
 104 protection, 3DES equivalent, for update operations (e.g. add, delete,
 105 modify, etc.).  See {{slapd.conf}}(5) for details.
 106
 107 For fine-grained control, SSFs may be used in access controls.  See
 108 {{SECT:Access Control}} section of the {{SECT:The slapd Configuration
 109 File}} for more information.
 110
 111
 112 H2: Authentication Methods
 113
 114 H3: "simple" method
 115
 116 The LDAP "simple" method has three modes of operation:
 117
 118 * anonymous,
 119 * unauthenticated, and
 120 * user/password authenticated.
 121
 122 Anonymous access is obtained by providing no name and no password
 123 to the "simple" bind operation.  Unauthenticated access is obtained
 124 by providing a name but no password.  Authenticated access is obtain
 125 by providing a valid name and password.
 126
 127 An anonymous bind results in an {{anonymous}} authorization.
 128 Anonymous bind mechanism is enabled by default, but can be disabled
 129 by specifying "{{EX:disallow bind_anon}}" in {{slapd.conf}}(5).
 130
 131 An unauthenticated bind results in an {{anonymous}} authorization.
 132 Unauthenticated bind mechanism is disabled by default, but can be
 133 enabled by specifying "{{EX:allow bind_anon_cred}}" in {{slapd.conf}}(5).
 134 As a number of LDAP applications mistakenly generate unauthenticated
 135 bind request when authenticated access was intended (that is, they
 136 do not ensure a password was provided), this mechanism should
 137 generally not be enabled.
 138
 139 A successful user/password authenticated bind results in a user
 140 authorization identity, the provided name, being associated with
 141 the session.  User/password authenticated bind is enabled by default.
 142 However, as this mechanism offers no evesdropping protection (e.g.,
 143 the password is set in the clear), it is recommended that it be
 144 used only in tightly controlled systems or when the LDAP session
 145 is protected by other means (e.g., TLS, {{TERM:IPSEC}}).  Where the
 146 administrator relies on TLS to protect the password, it is recommended
 147 that unprotected authentication be disabled.  This is done by setting
 148 "{{EX:disallow bind_simple_unprotected}}" in {{slapd.conf}}(5).
 149 The {{EX:security}} directive's {{EX:simple_bind}} option provides
 150 fine grain control over the level of confidential protection to
 151 require for {{simple}} user/password authentication.
 152
 153 The user/password authenticated bind mechanism can be completely
 154 disabled by setting "{{EX:disallow bind_simple}}".
 155
 156 Note:  An unsuccessful bind always results in the session having
 157 an {{anonymous}} authorization state.
 158
 159
 160 H3: SASL method
 161
 162 The LDAP SASL method allows use of any SASL authentication
 163 mechanism.  The {{SECT:Using SASL}} discusses use of SASL.
 164