Difference between revisions of "LDAP"

From RackTables Wiki
Jump to navigation Jump to search
Line 3: Line 3:
  
 
=== direct access to LDAP ===
 
=== direct access to LDAP ===
 +
The following settings configure direct communication with LDAP server:
 +
<pre>
 +
$user_auth_src = 'ldap';
 +
$require_local_account = FALSE;
 +
</pre>
 +
Further configuration is done through $LDAP_options array. Its contents 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.
 +
<pre>
 +
$LDAP_options = array
 +
(
 +
  # MANDATORY. Hostname or IP address of LDAP server(s). When multiple
 +
  # servers are listed (delimited with spaces), they are used in the order
 +
  # of appearance until a successful connection is made.
 +
  'server' => 'ldap.example.com',
 +
 +
  # OPTIONAL. This list of space-delimited attributes is used to build the
 +
  # "displayed name" of a user, which is used to print a greeting message.
 +
  'displayname_attrs' => 'givenname familyname',
 +
 +
  # CONDITIONAL. When this option is set, it is used for "domain"
 +
  # authentication mode specific to ActiveDirectory. In this mode the plain
 +
  # username presented by a user is joined with the configured domain name
 +
  # and the resulting string ("username@example.com") is used for password
 +
  # validation.
 +
  'domain' => 'example.com',
 +
 +
  # CONDITIONAL. This option enables "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.
 +
  'search_attr' => 'uid',
 +
  'search_dn' => 'OU=people,O=YourCompany',
 +
 +
  # MANDATORY. LDAP cache, values in seconds. Refresh, retry and expiry
 +
  # values are treated exactly as those for DNS SOA record. Example values
 +
  # 300-15-600 mean: unconditionally remeber successful auth for 5 minutes,
 +
  # after that still permit user access, but try to revalidate the password
 +
  # on the server (not more often, than once in 15 seconds). After 10
 +
  # minutes of unsuccessful retries give up and deny access until the LDAP
 +
  # server gets fixed.
 +
  #
 +
  # Like in DNS, the following condition must be always met:
 +
  # cache_retry <= cache_refresh <= cache_expiry
 +
  #
 +
  # To disable LDAP cache completely, set cache_refresh, cache_retry and
 +
  # cache_expiry to 0.
 +
  'cache_refresh' => 300,
 +
  'cache_retry' => 15,
 +
  'cache_expiry' => 600,
 +
 +
  # OPTIONAL. List of LDAP protocol options. The example below enables
 +
  # protocol version 3 (version 2, which is used by default, is often
 +
  # refused by modern LDAP servers) and disables referrals (this makes LDAP
 +
  # search happen in the base DN, but not in one of nested OUs/CNs, which
 +
  # is important for some ActiveDirectory servers).
 +
  'options' => array (LDAP_OPT_PROTOCOL_VERSION => 3, LDAP_OPT_REFERRALS => 0),
 +
);
 +
</pre>
  
 
=== trusting httpd ===
 
=== trusting httpd ===

Revision as of 23:36, 9 June 2011

LDAP configuration and troubleshooting

There are different ways to make RackTables recognize LDAP accounts instead of local accounts. One way is to configure RackTables to communicate with an LDAP server directly. In this case both password validity and group membership information are available inside RackTables. Group membership can be used in permission rules to implement site's access control policy. Another way is to configure RackTables to trust the authentication already performed by httpd, which in turn is configured to authenticate HTTP(S) clients in LDAP. This is sometimes the case, when the system administrator wants to reuse a working httpd+mod_auth_ldap setup. The drawback of this method is that group membership information wouldn't be available at RackTables level.

direct access to LDAP

The following settings configure direct communication with LDAP server:

$user_auth_src = 'ldap';
$require_local_account = FALSE;

Further configuration is done through $LDAP_options array. Its contents 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.

$LDAP_options = array
(
  # MANDATORY. Hostname or IP address of LDAP server(s). When multiple
  # servers are listed (delimited with spaces), they are used in the order
  # of appearance until a successful connection is made.
  'server' => 'ldap.example.com',

  # OPTIONAL. This list of space-delimited attributes is used to build the
  # "displayed name" of a user, which is used to print a greeting message.
  'displayname_attrs' => 'givenname familyname',

  # CONDITIONAL. When this option is set, it is used for "domain"
  # authentication mode specific to ActiveDirectory. In this mode the plain
  # username presented by a user is joined with the configured domain name
  # and the resulting string ("username@example.com") is used for password
  # validation.
  'domain' => 'example.com',

  # CONDITIONAL. This option enables "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.
  'search_attr' => 'uid',
  'search_dn' => 'OU=people,O=YourCompany',

  # MANDATORY. LDAP cache, values in seconds. Refresh, retry and expiry
  # values are treated exactly as those for DNS SOA record. Example values
  # 300-15-600 mean: unconditionally remeber successful auth for 5 minutes,
  # after that still permit user access, but try to revalidate the password
  # on the server (not more often, than once in 15 seconds). After 10
  # minutes of unsuccessful retries give up and deny access until the LDAP
  # server gets fixed.
  #
  # Like in DNS, the following condition must be always met:
  # cache_retry <= cache_refresh <= cache_expiry
  #
  # To disable LDAP cache completely, set cache_refresh, cache_retry and
  # cache_expiry to 0.
  'cache_refresh' => 300,
  'cache_retry' => 15,
  'cache_expiry' => 600,

  # OPTIONAL. List of LDAP protocol options. The example below enables
  # protocol version 3 (version 2, which is used by default, is often
  # refused by modern LDAP servers) and disables referrals (this makes LDAP
  # search happen in the base DN, but not in one of nested OUs/CNs, which
  # is important for some ActiveDirectory servers).
  'options' => array (LDAP_OPT_PROTOCOL_VERSION => 3, LDAP_OPT_REFERRALS => 0),
);

trusting httpd

$user_auth_src = 'httpd';
$require_local_account = FALSE;