LDAP - Revision history

Infrastation: /* direct access to LDAP */ describe the "port" parameter

2016-03-04T10:56:55Z

direct access to LDAP: describe the "port" parameter

Tleavitt: his to "his or her"

2016-01-13T21:54:12Z

his to "his or her"

Tleavitt: fixed typo

2016-01-13T21:52:33Z

fixed typo

Sgroat: /* direct access to LDAP */

2015-04-28T19:20:46Z

direct access to LDAP

Sgroat: /* trusting httpd */

2015-04-28T19:20:25Z

trusting httpd

Infrastation: /* direct access to LDAP */

2012-04-05T17:18:40Z

direct access to LDAP

Hg-xing: Added description of search_bind_rdn/password.

2012-03-19T09:40:29Z

Added description of search_bind_rdn/password.

Infrastation: /* a note on LDAP protocol versions */ merge "allow bind_v2" info

2012-03-16T12:51:58Z

a note on LDAP protocol versions: merge "allow bind_v2" info

Infrastation: /* direct access to LDAP */ protocol version is now a subsection

2012-03-16T11:30:58Z

direct access to LDAP: protocol version is now a subsection

Infrastation: /* direct access to LDAP */

2012-02-15T14:51:53Z

direct access to LDAP

@@ Line 18: / Line 18: @@
 The first setting makes RackTables execute the configuration defined in <tt>$LDAP_options</tt>. The second option makes RackTables accept any valid account existing in LDAP. Historically a user is required to be on the list of local accounts regardless of how his or her password is verified. For most LDAP environments this restriction makes no sense.
-Further configuration is done through $LDAP_options array. Its content varies in each particular environment depending on the type of LDAP server software, its schema and configuration. RackTables has been reported to work with OpenLDAP, ActiveDirectory and eDirectory servers. Meaning of each LDAP option is explained below. '''The table is accurate as of RackTables release 0.19.12.'''
+Further configuration is done through $LDAP_options array. Its content varies in each particular environment depending on the type of LDAP server software, its schema and configuration. RackTables has been reported to work with OpenLDAP, ActiveDirectory and eDirectory servers. Meaning of each LDAP option is explained below. '''The table is accurate as of RackTables release 0.20.8.'''
 {| border=1
 |-
@@ Line 33: / Line 33: @@
 A more complete description of connection handling performed by PHP LDAP extension can be found in [http://php.net/ldap_connect ldap_connect function documentation].
 |-
 | <tt>domain</tt>

@@ Line 16: / Line 16: @@
 $require_local_account = FALSE;
 </pre>
-The first setting makes RackTables execute the configuration defined in <tt>$LDAP_options</tt>. The second option makes RackTables accept any valid account existing in LDAP. Historically a user is required to be on the list of local accounts regardless of how his password is verified. For most LDAP environments this restriction makes no sense.
+The first setting makes RackTables execute the configuration defined in <tt>$LDAP_options</tt>. The second option makes RackTables accept any valid account existing in LDAP. Historically a user is required to be on the list of local accounts regardless of how his or her password is verified. For most LDAP environments this restriction makes no sense.
 Further configuration is done through $LDAP_options array. Its content varies in each particular environment depending on the type of LDAP server software, its schema and configuration. RackTables has been reported to work with OpenLDAP, ActiveDirectory and eDirectory servers. Meaning of each LDAP option is explained below. '''The table is accurate as of RackTables release 0.19.12.'''

@@ Line 16: / Line 16: @@
 $require_local_account = FALSE;
 </pre>
-The first setting makes RackTables execute the configuration defined in <tt>$LDAP_options</tt>. The second option makes RackTables accept any valid account existing in LDAP. Historically a user is required to be on the list of local accounts regardless of how his password is verified. For most LDAP enviroments this restriction makes no sense.
+The first setting makes RackTables execute the configuration defined in <tt>$LDAP_options</tt>. The second option makes RackTables accept any valid account existing in LDAP. Historically a user is required to be on the list of local accounts regardless of how his password is verified. For most LDAP environments this restriction makes no sense.
 Further configuration is done through $LDAP_options array. Its content varies in each particular environment depending on the type of LDAP server software, its schema and configuration. RackTables has been reported to work with OpenLDAP, ActiveDirectory and eDirectory servers. Meaning of each LDAP option is explained below. '''The table is accurate as of RackTables release 0.19.12.'''

@@ Line 11: / Line 11: @@
 == direct access to LDAP ==
 The following settings configure direct communication with LDAP server. '''Note that if your LDAP configuration doesn't work, you can revert to local passwords by setting <tt>$user_auth_src = 'database'</tt>.'''
 <pre>
 $user_auth_src = 'ldap';

@@ Line 3: / Line 3: @@
 == trusting httpd ==
 <pre>
 $user_auth_src = 'httpd';

@@ Line 39: / Line 39: @@
 | <span style="background-color:yellow;">varies</span>
 | These options enable "search" authentication mode, which is more common for OpenLDAP and eDirectory servers. It is assumed, that many nested organizational units (OUs) exist within within an organization (O). Traditional LDAP implementations let each OU have its own list of usernames, and some usernames remain unique only within their OU. The following approach is used to distinguish the users. Users with globally unique usernames present their plain username. Other users know, that they have to use their UID instead. A LDAP database is maintaned so, that UID is a little longer, than username, but yet unique. To map presented UID into common name (CN, which is the canonical, long form of user's identifier) LDAP search is performed. All this works automatically, once the search DN and search attribute are configured. '''At least one of "domain" and "search" modes must be enabled.'''
 |-
 | <tt>displayname_attrs</tt>

@@ Line 76: / Line 76: @@
 === a note on LDAP protocol versions ===
-PHP LDAP extension often uses LDAP protocol version 2 by default, which is deprecated. All examples below include a setting to use LDAP protocol version 3.
+Most modern LDAP servers are configured to allow only version 3 LDAP clients, even if the server has support for version 2 (which is considered legacy). Although PHP LDAP extension supports both version 2 and version 3 of the protocol, it often defaults to version 2 unless explicitly requested to use version 3. This breaks an otherwise properly configured RackTables instance.
 === configuring for OpenLDAP in "search" mode ===

@@ Line 60: / Line 60: @@
 | <tt>options</tt>
 | <span style="background-color:green;">no</span>
-| List of LDAP protocol options as explained at http://php.net/manual/en/function.ldap-set-option.php PHP LDAP extension often uses LDAP protocol version 2 by default, which is deprecated. All examples below include a setting to use LDAP protocol version 3.
+| List of LDAP protocol options as explained at http://php.net/manual/en/function.ldap-set-option.php (see the note on LDAP protocol version below).
 |-
 | <tt>use_tls</tt>
@@ Line 72: / Line 72: @@
 |}
-'''A note on the "domain+search" mode.''' It is possible to have both "domain" and "search" modes enabled. In this case "domain" mode will be used for password validation and "search" mode will be used to retrieve <tt>displayname_attrs</tt> and <tt>group_attr</tt> data. The current limitation is that <tt>group_attr</tt> is not processed without <tt>displayname_attrs</tt> configured, this is probably a bug.
+=== a note on the "domain+search" mode ===
 === configuring for OpenLDAP in "search" mode ===

@@ Line 69: / Line 69: @@
 * If it's set to 2, then TLS is mandatory and if the negotiation fails, it throws an exception. A TLS negotiation failure generally indicates a serious security policy failure + configuration problem, so it's probably better to make noise about a problem like this rather than pretending nothing happened and that this was a minor issue. It also makes debugging much easier.
-'''LDAP TLS requires LDAPv3.'''
+'''LDAP TLS requires LDAPv3. This option was added in release 0.19.11.'''
 |}