+
+
+H2: Data Integrity and Confidentiality Protection
+
+{{TERM[expand]TLS}} (TLS) can be used to provide data integrity and
+confidentiality protection. OpenLDAP supports negotiation of
+{{TERM:TLS}} ({{TERM:SSL}}) via both StartTLS and {{F:ldaps://}}.
+See the {{SECT:Using TLS}} chapter for more information. StartTLS
+is the standard track mechanism.
+
+A number of {{TERM[expand]SASL}} (SASL) mechanisms, such as DIGEST-MD5
+and {{TERM:GSSAPI}}, also provide data 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
+association. Anonymous bind mechanism is enabled by default, but
+can be disabled by specifying "{{EX:disallow bind_anon}}" in
+{{slapd.conf}}(5).
+
+An unauthenticated bind also results in an {{anonymous}} authorization
+association. 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 remain disabled.
+
+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 itself 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 association.
+
+
+H3: SASL method
+
+The LDAP {{TERM:SASL}} method allows use of any SASL authentication
+mechanism. The {{SECT:Using SASL}} discusses use of SASL.
+