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