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 supports 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 {{F:ldap://}}
  41 sessions and port 636/tcp for {{F:ldaps://}}) sessions.  {{slapd}}(8)
  42 may be configured to listen on other ports.
  43
  44 As specifics of how to configure IP firewall are dependent on the
  45 particular kind of IP firewall used, no examples are provided here.
  46 See the document associated with your IP firewall.
  47
  48
  49 H3: TCP Wrappers
  50
  51 {{slapd}}(8) supports {{TERM:TCP}} Wrappers.  TCP Wrappers provide
  52 a rule-based access control system for controlling TCP/IP access
  53 to the server.  For example, the {{host_options}}(5) rule:
  54
  55 >       slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
  56 >       slapd: ALL : DENY
  57
  58 allows only incoming connections from the private network {{F:10.0.0.0}}
  59 and localhost ({{F:127.0.0.1}}) to access the directory service.
  60 Note that IP addresses are used as {{slapd}}(8) is not normally
  61 configured to perform reverse lookups.
  62
  63 It is noted that TCP wrappers require the connection to be accepted.
  64 As significant processing is required just to deny a connection,
  65 it is generally advised that IP firewall protection be used instead
  66 of TCP wrappers.
  67
  68 See {{hosts_access}}(5) for more information on TCP wrapper rules.
  69
  70
  71 H2: Data Integrity and Confidentiality Protection
  72
  73 {{TERM[expand]TLS}} (TLS) can be used to provide data integrity and
  74 confidentiality protection.  OpenLDAP supports negotiation of
  75 {{TERM:TLS}} ({{TERM:SSL}}) via both StartTLS and {{F:ldaps://}}.
  76 See the {{SECT:Using TLS}} chapter for more information.  StartTLS
  77 is the standard track mechanism.
  78
  79 A number of {{TERM[expand]SASL}} (SASL) mechanisms, such as DIGEST-MD5
  80 and {{TERM:GSSAPI}}, also provide data integrity and confidentiality
  81 protection.  See the {{SECT:Using SASL}} chapter for more information.
  82
  83
  84 H3: Security Strength Factors
  85
  86 The server uses {{TERM[expand]SSF}}s (SSF) to indicate the relative
  87 strength of protection.  A SSF of zero (0) indicates no protections
  88 are in place.  A SSF of one (1) indicates integrity protection are
  89 in place.  A SSF greater than one (>1) roughly correlates to the
  90 effective encryption key length.  For example, {{TERM:DES}} is 56,
  91 {{TERM:3DES}} is 112, and {{TERM:AES}} 128, 192, or 256.
  92
  93 A number of administrative controls rely on SSFs associated with
  94 TLS and SASL protection in place on an LDAP session.
  95
  96 {{EX:security}} controls disallow operations when appropriate
  97 protections are not in place.  For example:
  98
  99 >       security ssf=1 update_ssf=112
 100
 101 requires integrity protection for all operations and encryption
 102 protection, 3DES equivalent, for update operations (e.g. add, delete,
 103 modify, etc.).  See {{slapd.conf}}(5) for details.
 104
 105 For fine-grained control, SSFs may be used in access controls.  See
 106 {{SECT:Access Control}} section of the {{SECT:The slapd Configuration
 107 File}} for more information.
 108
 109
 110 H2: Authentication Methods
 111
 112 H3: "simple" method
 113
 114 The LDAP "simple" method has three modes of operation:
 115
 116 * anonymous,
 117 * unauthenticated, and
 118 * user/password authenticated.
 119
 120 Anonymous access is obtained by providing no name and no password
 121 to the "simple" bind operation.  Unauthenticated access is obtained
 122 by providing a name but no password.  Authenticated access is obtain
 123 by providing a valid name and password.
 124
 125 An anonymous bind results in an {{anonymous}} authorization
 126 association.  Anonymous bind mechanism is enabled by default, but
 127 can be disabled by specifying "{{EX:disallow bind_anon}}" in
 128 {{slapd.conf}}(5).
 129
 130 An unauthenticated bind also results in an {{anonymous}} authorization
 131 association.  Unauthenticated bind mechanism is disabled by default,
 132 but can be enabled by specifying "{{EX:allow bind_anon_cred}}" in
 133 {{slapd.conf}}(5).  As a number of LDAP applications mistakenly
 134 generate unauthenticated bind request when authenticated access was
 135 intended (that is, they do not ensure a password was provided),
 136 this mechanism should generally remain disabled.
 137
 138 A successful user/password authenticated bind results in a user
 139 authorization identity, the provided name, being associated with
 140 the session.  User/password authenticated bind is enabled by default.
 141 However, as this mechanism itself offers no evesdropping protection
 142 (e.g., the password is set in the clear), it is recommended that
 143 it be used only in tightly controlled systems or when the LDAP
 144 session is protected by other means (e.g., TLS, {{TERM:IPSEC}}).
 145 Where the administrator relies on TLS to protect the password, it
 146 is recommended that unprotected authentication be disabled.  This
 147 is done by setting "{{EX:disallow bind_simple_unprotected}}" in
 148 {{slapd.conf}}(5).  The {{EX:security}} directive's {{EX:simple_bind}}
 149 option provides fine grain control over the level of confidential
 150 protection to require for {{simple}} user/password authentication.
 151
 152 The user/password authenticated bind mechanism can be completely
 153 disabled by setting "{{EX:disallow bind_simple}}".
 154
 155 Note:  An unsuccessful bind always results in the session having
 156 an {{anonymous}} authorization association.
 157
 158
 159 H3: SASL method
 160
 161 The LDAP {{TERM:SASL}} method allows use of any SASL authentication
 162 mechanism.  The {{SECT:Using SASL}} discusses use of SASL.
 163