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

   1 # $OpenLDAP$
   2 # Copyright 1999-2008 The OpenLDAP Foundation, All Rights Reserved.
   3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
   4
   5 H1: Security Considerations
   6
   7 OpenLDAP Software is designed to run in a wide variety of computing
   8 environments from tightly-controlled closed networks to the global
   9 Internet.  Hence, OpenLDAP Software supports many different security
  10 mechanisms.  This chapter describes these mechanisms and discusses
  11 security considerations for using OpenLDAP Software.
  12
  13 H2: Network Security
  14
  15 H3: Selective Listening
  16
  17 By default, {{slapd}}(8) will listen on both the IPv4 and IPv6 "any"
  18 addresses.  It is often desirable to have {{slapd}} listen on select
  19 address/port pairs.  For example, listening only on the IPv4 address
  20 {{EX:127.0.0.1}} will disallow remote access to the directory server.
  21 E.g.:
  22
  23 >       slapd -h ldap://127.0.0.1
  24
  25 While the server can be configured to listen on a particular interface
  26 address, this doesn't necessarily restrict access to the server to
  27 only those networks accessible via that interface.   To selective
  28 restrict remote access, it is recommend that an {{SECT:IP Firewall}}
  29 be used to restrict access.
  30
  31 See {{SECT:Command-line Options}} and {{slapd}}(8) for more
  32 information.
  33
  34
  35 H3: IP Firewall
  36
  37 {{TERM:IP}} firewall capabilities of the server system can be used
  38 to restrict access based upon the client's IP address and/or network
  39 interface used to communicate with the client.
  40
  41 Generally, {{slapd}}(8) listens on port 389/tcp for {{F:ldap://}}
  42 sessions and port 636/tcp for {{F:ldaps://}}) sessions.  {{slapd}}(8)
  43 may be configured to listen on other ports.
  44
  45 As specifics of how to configure IP firewall are dependent on the
  46 particular kind of IP firewall used, no examples are provided here.
  47 See the document associated with your IP firewall.
  48
  49
  50 H3: TCP Wrappers
  51
  52 {{slapd}}(8) supports {{TERM:TCP}} Wrappers.  TCP Wrappers provide
  53 a rule-based access control system for controlling TCP/IP access
  54 to the server.  For example, the {{host_options}}(5) rule:
  55
  56 >       slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
  57 >       slapd: ALL : DENY
  58
  59 allows only incoming connections from the private network {{F:10.0.0.0}}
  60 and localhost ({{F:127.0.0.1}}) to access the directory service.
  61 Note that IP addresses are used as {{slapd}}(8) is not normally
  62 configured to perform reverse lookups.
  63
  64 It is noted that TCP wrappers require the connection to be accepted.
  65 As significant processing is required just to deny a connection,
  66 it is generally advised that IP firewall protection be used instead
  67 of TCP wrappers.
  68
  69 See {{hosts_access}}(5) for more information on TCP wrapper rules.
  70
  71
  72 H2: Data Integrity and Confidentiality Protection
  73
  74 {{TERM[expand]TLS}} (TLS) can be used to provide data integrity and
  75 confidentiality protection.  OpenLDAP supports negotiation of
  76 {{TERM:TLS}} ({{TERM:SSL}}) via both StartTLS and {{F:ldaps://}}.
  77 See the {{SECT:Using TLS}} chapter for more information.  StartTLS
  78 is the standard track mechanism.
  79
  80 A number of {{TERM[expand]SASL}} (SASL) mechanisms, such as
  81 {{TERM:DIGEST-MD5}} and {{TERM:GSSAPI}}, also provide data integrity
  82 and confidentiality protection.  See the {{SECT:Using SASL}} chapter
  83 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.
 108 See {{SECT:The access Configuration Directive}} section of the
 109 {{SECT:The slapd Configuration 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 requested by providing no name and no password
 123 to the "simple" bind operation.  Unauthenticated access is requested
 124 by providing a name but no password.  Authenticated access is
 125 requested by providing a valid name and password.
 126
 127 An anonymous bind results in an {{anonymous}} authorization
 128 association.  Anonymous bind mechanism is enabled by default, but
 129 can be disabled by specifying "{{EX:disallow bind_anon}}" in
 130 {{slapd.conf}}(5).  Note that disabling the anonymous bind mechanism
 131 does not prevent anonymous access to the directory.  To require
 132 authentication to access the directory, one should instead
 133 specify "{{EX:require authc}}".
 134
 135 An unauthenticated bind also results in an {{anonymous}} authorization
 136 association.  Unauthenticated bind mechanism is disabled by default,
 137 but can be enabled by specifying "{{EX:allow bind_anon_cred}}" in
 138 {{slapd.conf}}(5).  As a number of LDAP applications mistakenly
 139 generate unauthenticated bind request when authenticated access was
 140 intended (that is, they do not ensure a password was provided),
 141 this mechanism should generally remain disabled.
 142
 143 A successful user/password authenticated bind results in a user
 144 authorization identity, the provided name, being associated with
 145 the session.  User/password authenticated bind is enabled by default.
 146 However, as this mechanism itself offers no eavesdropping protection
 147 (e.g., the password is set in the clear), it is recommended that
 148 it be used only in tightly controlled systems or when the LDAP
 149 session is protected by other means (e.g., TLS, {{TERM:IPsec}}).
 150 Where the administrator relies on TLS to protect the password, it
 151 is recommended that unprotected authentication be disabled.  This
 152 is done using the {{EX:security}} directive's {{EX:simple_bind}}
 153 option, which provides fine grain control over the level of confidential
 154 protection to require for {{simple}} user/password authentication.
 155 E.g., using {{EX:security simple_bind=56}} would require {{simple}}
 156 binds to use encryption of DES equivalent or better.
 157
 158 The user/password authenticated bind mechanism can be completely
 159 disabled by setting "{{EX:disallow bind_simple}}".
 160
 161 Note:  An unsuccessful bind always results in the session having
 162 an {{anonymous}} authorization association.
 163
 164
 165 H3: SASL method
 166
 167 The LDAP {{TERM:SASL}} method allows use of any SASL authentication
 168 mechanism.  The {{SECT:Using SASL}} discusses use of SASL.
 169