mirror of
https://github.com/apache/httpd.git
synced 2025-10-22 23:12:44 +03:00
d2b89ddd10
<compatibility> info to mod_auth_ldap. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96599 13f79535-47bb-0310-9956-ffa450edef68
722 lines
45 KiB
Plaintext
722 lines
45 KiB
Plaintext
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><!--
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
This file is generated from xml source: DO NOT EDIT
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
--><title>mod_auth_ldap - Apache HTTP Server</title><link href="../style/manual.css" type="text/css" rel="stylesheet"></head><body><blockquote><div align="center"><img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]"><h3>Apache HTTP Server Version 2.0</h3></div><h1 align="center">Apache Module mod_auth_ldap</h1><table cellspacing="1" cellpadding="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap" valign="top"><span class="help">Description:
|
|
</span></td><td>Allows an LDAP directory to be used to store the database
|
|
for HTTP Basic authentication.</td></tr><tr><td nowrap="nowrap"><a href="module-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="module-dict.html#ModuleIdentifier" class="help">Module Identifier:
|
|
</a></td><td>auth_ldap_module</td></tr><tr><td align="left" valign="top"><a href="module-dict.html#Compatibility" class="help">Compatibility:
|
|
</a></td><td><compatibility>Available in version 2.0.41 and later</compatibility></td></tr></table></td></tr></table><h2>Summary</h2>
|
|
<p><code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> supports the following features:</p>
|
|
|
|
<ul>
|
|
<li>Known to support the <a href="http://www.openldap.org/">OpenLDAP SDK</a> (both 1.x
|
|
and 2.x), and the <a href="http://www.iplanet.com/downloads/developer/">iPlanet
|
|
(Netscape)</a> SDK.</li>
|
|
|
|
<li>Complex authorization policies can be implemented by
|
|
representing the policy with LDAP filters.</li>
|
|
|
|
<li>Support for Microsoft FrontPage allows FrontPage users to
|
|
control access to their webs, while retaining LDAP for user
|
|
authentication.</li>
|
|
|
|
<li>Uses extensive caching of LDAP operations via <a href="mod_ldap.html">mod_ldap</a>.</li>
|
|
|
|
<li>Support for LDAP over SSL (requires the Netscape SDK) or
|
|
TLS (requires the OpenLDAP 2.x SDK).</li>
|
|
</ul>
|
|
<h2>Directives</h2><ul><li><a href="#authldapauthoritative">AuthLDAPAuthoritative</a></li><li><a href="#authldapbinddn">AuthLDAPBindDN</a></li><li><a href="#authldapbindpassword">AuthLDAPBindPassword</a></li><li><a href="#authldapcomparednonserver">AuthLDAPCompareDNOnServer</a></li><li><a href="#authldapdereferencealiases">AuthLDAPDereferenceAliases</a></li><li><a href="#authldapenabled">AuthLDAPEnabled</a></li><li><a href="#authldapfrontpagehack">AuthLDAPFrontPageHack</a></li><li><a href="#authldapgroupattribute">AuthLDAPGroupAttribute</a></li><li><a href="#authldapgroupattributeisdn">AuthLDAPGroupAttributeIsDN</a></li><li><a href="#authldapremoteuserisdn">AuthLDAPRemoteUserIsDN</a></li><li><a href="#authldapstarttls directive">AuthLDAPStartTLS directive</a></li><li><a href="#authldapurl">AuthLDAPUrl</a></li></ul><p><strong>See also </strong></p><ul><li><code><a href="../mod/mod_ldap.html">mod_ldap</a></code></li></ul><h2><a name="contents">Contents</a></h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="#operation">Operation</a>
|
|
|
|
<ul>
|
|
<li><a href="#authenphase">The Authentication
|
|
Phase</a></li>
|
|
|
|
<li><a href="#authorphase">The Authorization
|
|
Phase</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#requiredirectives">The require Directives</a>
|
|
|
|
<ul>
|
|
<li><a href="#reqvaliduser">require valid-user</a></li>
|
|
|
|
<li><a href="#requser">require user</a></li>
|
|
|
|
<li><a href="#reqgroup">require group</a></li>
|
|
|
|
<li><a href="#reqdn">require dn</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li><a href="#examples">Examples</a></li>
|
|
|
|
<li><a href="#usingtls">Using TLS</a></li>
|
|
|
|
<li><a href="#usingssl">Using SSL</a></li>
|
|
|
|
<li>
|
|
<a href="#frontpage">Using Microsoft FrontPage with
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code></a>
|
|
|
|
<ul>
|
|
<li><a href="#howitworks">How It Works</a></li>
|
|
|
|
<li><a href="#fpcaveats">Caveats</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<h2><a name="operation">Operation</a></h2>
|
|
|
|
<p>There are two phases in granting access to a user. The first
|
|
phase is authentication, in which <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code>
|
|
verifies that the user's credentials are valid. This also called
|
|
the <em>search/bind</em> phase. The second phase is
|
|
authorization, in which <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> determines
|
|
if the authenticated user is allowed access to the resource in
|
|
question. This is also known as the <em>compare</em>
|
|
phase.</p>
|
|
|
|
<h3><a name="authenphase">The Authentication
|
|
Phase</a></h3>
|
|
|
|
<p>During the authentication phase, <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code>
|
|
searches for an entry in the directory that matches the username
|
|
that the HTTP client passes. If a single unique match is found,
|
|
then <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> attempts to bind to the
|
|
directory server using the DN of the entry plus the password
|
|
provided by the HTTP client. Because it does a search, then a
|
|
bind, it is often referred to as the search/bind phase. Here are
|
|
the steps taken during the search/bind phase.</p>
|
|
|
|
<ol>
|
|
<li>Generate a search filter by combining the attribute and
|
|
filter provided in the <a href="#authldapurl" class="directive"><code class="directive">AuthLDAPURL</code></a> directive with
|
|
the username passed by the HTTP client.</li>
|
|
|
|
<li>Search the directory using the generated filter. If the
|
|
search does not return exactly one entry, deny or decline
|
|
access.</li>
|
|
|
|
<li>Fetch the distinguished name of the entry retrieved from
|
|
the search and attempt to bind to the LDAP server using the
|
|
DN and the password passed by the HTTP client. If the bind is
|
|
unsuccessful, deny or decline access.</li>
|
|
</ol>
|
|
|
|
<p>The following directives are used during the search/bind
|
|
phase</p>
|
|
|
|
<table>
|
|
<tr>
|
|
<td><a href="#authldapurl" class="directive"><code class="directive">AuthLDAPURL</code></a></td>
|
|
|
|
<td>Specifies the LDAP server, the
|
|
base DN, the attribute to use in the search, as well as the
|
|
extra search filter to use.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#authldapbinddn" class="directive"><code class="directive">AuthLDAPBindDN</code></a></td>
|
|
|
|
<td>An optional DN to bind with
|
|
during the search phase.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#authldapbindpassword" class="directive"><code class="directive">AuthLDAPBindPassword</code></a></td>
|
|
|
|
<td>An optional password to bind
|
|
with during the search phase.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
|
|
<h3><a name="authorphase">The Authorization
|
|
Phase</a></h3>
|
|
|
|
<p>During the authorization phase, <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code>
|
|
attempts to determine if the user is authorized to access the
|
|
resource. Many of these checks require
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> to do a compare operation on the
|
|
LDAP server. This is why this phase is often referred to as the
|
|
compare phase. <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> accepts the
|
|
following <a href="../mod/core.html#require" class="directive"><code class="directive">Require</code></a>
|
|
directives to determine if the credentials are acceptable:</p>
|
|
|
|
<ul>
|
|
<li>Grant access if there is a <a href="#requser"><code>require
|
|
valid-user</code></a> directive.</li>
|
|
|
|
<li>Grant access if there is a <a href="#reqgroup"><code>require user</code></a> directive, and the
|
|
username in the directive matches the username passed by the
|
|
client.</li>
|
|
|
|
<li>Grant access if there is a <a href="#reqdn"><code>require
|
|
dn</code></a> directive, and the DN in the directive matches
|
|
the DN fetched from the LDAP directory.</li>
|
|
|
|
<li>Grant access if there is a <a href="#reqgroup"><code>require group</code></a> directive, and
|
|
the DN fetched from the LDAP directory (or the username
|
|
passed by the client) occurs in the LDAP group.</li>
|
|
|
|
<li>otherwise, deny or decline access</li>
|
|
</ul>
|
|
|
|
<p><code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> uses the following directives during the
|
|
compare phase:</p>
|
|
|
|
<table>
|
|
<tr>
|
|
<td><a href="#authldapurl" class="directive"><code class="directive">AuthLDAPURL</code></a> </td>
|
|
|
|
<td>The attribute specified in the
|
|
URL is used in compare operations for the <code>require
|
|
user</code> operation.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#authldapcomparednonserver" class="directive"><code class="directive">AuthLDAPCompareDNOnServer</code></a></td>
|
|
|
|
<td>Determines the behavior of the
|
|
<code>require dn</code> directive.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#authldapgroupattribute" class="directive"><code class="directive">AuthLDAPGroupAttribute</code></a></td>
|
|
|
|
<td>Determines the attribute to
|
|
use for comparisons in the <code>require group</code>
|
|
directive.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#authldapgroupattributeisdn" class="directive"><code class="directive">AuthLDAPGroupAttributeIsDN</code></a></td>
|
|
|
|
<td>Specifies whether to use the
|
|
user DN or the username when doing comparisons for the
|
|
<code>require group</code> directive.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2><a name="requiredirectives">The require Directives</a></h2>
|
|
|
|
<p>Apache's <a href="../mod/core.html#require" class="directive"><code class="directive">Require</code></a>
|
|
directives are used during the authorization phase to ensure that
|
|
a user is allowed to access a resource.</p>
|
|
|
|
<h3><a name="reqvaliduser">require
|
|
valid-user</a></h3>
|
|
|
|
<p>If this directive exists, <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> grants
|
|
access to any user that has successfully authenticated during the
|
|
search/bind phase.</p>
|
|
|
|
|
|
<h3><a name="requser">require user</a></h3>
|
|
|
|
<p>The <code>require user</code> directive specifies what
|
|
usernames can access the resource. Once
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> has retrieved a unique DN from the
|
|
directory, it does an LDAP compare operation using the username
|
|
specified in the <code>require user</code> to see if that username
|
|
is part of the just-fetched LDAP entry. Multiple users can be
|
|
granted access by putting multiple usernames on the line,
|
|
separated with spaces. If a username has a space in it, then it
|
|
must be the only user on the line. In this case, multiple users
|
|
can be granted access by using multiple <code>require user</code>
|
|
directives, with one user per line. For example, with a <a href="#authldapurl" class="directive"><code class="directive">AuthLDAPURL</code></a> of
|
|
<code>ldap://ldap/o=Airius?cn</code> (i.e., <code>cn</code> is
|
|
used for searches), the following require directives could be used
|
|
to restrict access:</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
require user Barbara Jenson<br>
|
|
require user Fred User<br>
|
|
require user Joe Manager<br>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>Because of the way that <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> handles this
|
|
directive, Barbara Jenson could sign on as <em>Barbara
|
|
Jenson</em>, <em>Babs Jenson</em> or any other <code>cn</code> that
|
|
she has in her LDAP entry. Only the single <code>require
|
|
user</code> line is needed to support all values of the attribute
|
|
in the user's entry.</p>
|
|
|
|
<p>If the <code>uid</code> attribute was used instead of the
|
|
<code>cn</code> attribute in the URL above, the above three lines
|
|
could be condensed to</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>require user bjenson fuser jmanager</code></td></tr></table></blockquote>
|
|
|
|
|
|
<h3><a name="reqgroup">require group</a></h3>
|
|
|
|
<p>This directive specifies an LDAP group whose members are
|
|
allowed access. It takes the distinguished name of the LDAP
|
|
group. For example, assume that the following entry existed in
|
|
the LDAP directory:</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
dn: cn=Administrators, o=Airius<br>
|
|
objectClass: groupOfUniqueNames<br>
|
|
uniqueMember: cn=Barbara Jenson, o=Airius<br>
|
|
uniqueMember: cn=Fred User, o=Airius<br>
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>The following directive would grant access to both Fred and
|
|
Barbara:</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>require group cn=Administrators, o=Airius</code></td></tr></table></blockquote>
|
|
|
|
<p>Behavior of this directive is modified by the <a href="#authldapgroupattribute" class="directive"><code class="directive">AuthLDAPGroupAttribute</code></a> and
|
|
<a href="#authldapgroupattributeisdn" class="directive"><code class="directive">AuthLDAPGroupAttributeIsDN</code></a>
|
|
directives.</p>
|
|
|
|
|
|
<h3><a name="reqdn">require dn</a></h3>
|
|
|
|
<p>The <code>require dn</code> directive allows the administrator
|
|
to grant access based on distinguished names. It specifies a DN
|
|
that must match for access to be granted. If the distinguished
|
|
name that was retrieved from the directory server matches the
|
|
distinguished name in the <code>require dn</code>, then
|
|
authorization is granted.</p>
|
|
|
|
<p>The following directive would grant access to a specific
|
|
DN:</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>require dn cn=Barbara Jenson, o=Airius</code></td></tr></table></blockquote>
|
|
|
|
<p>Behavior of this directive is modified by the <a href="#authldapcomparednonserver" class="directive"><code class="directive">AuthLDAPCompareDNOnServer</code></a>
|
|
directive.</p>
|
|
|
|
<h2><a name="examples">Examples</a></h2>
|
|
|
|
<ul>
|
|
<li>
|
|
Grant access to anyone who exists in the LDAP directory,
|
|
using their UID for searches.
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
AuthLDAPURL ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)<br>
|
|
require valid-user
|
|
</code></td></tr></table></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
The next example is the same as above; but with the fields
|
|
that have useful defaults omitted. Also, note the use of a
|
|
redundant LDAP server.
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>AuthLDAPURL ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius<br>
|
|
require valid-user
|
|
</code></td></tr></table></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
The next example is similar to the previous one, but is
|
|
uses the common name instead of the UID. Note that this
|
|
could be problematical if multiple people in the directory
|
|
share the same <code>cn</code>, because a search on <code>cn</code>
|
|
<strong>must</strong> return exactly one entry. That's why
|
|
this approach is not recommended: it's a better idea to
|
|
choose an attribute that is guaranteed unique in your
|
|
directory, such as <code>uid</code>.
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
AuthLDAPURL ldap://ldap.airius.com/ou=People, o=Airius?cn<br>
|
|
require valid-user
|
|
</code></td></tr></table></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
Grant access to anybody in the Administrators group. The
|
|
users must authenticate using their UID.
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid<br>
|
|
require group cn=Administrators, o=Airius
|
|
</code></td></tr></table></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
The next example assumes that everyone at Airius who
|
|
carries an alphanumeric pager will have an LDAP attribute
|
|
of <code>qpagePagerID</code>. The example will grant access
|
|
only to people (authenticated via their UID) who have
|
|
alphanumeric pagers:
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)<br>
|
|
require valid-user
|
|
</code></td></tr></table></blockquote>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The next example demonstrates the power of using filters
|
|
to accomplish complicated administrative requirements.
|
|
Without filters, it would have been necessary to create a
|
|
new LDAP group and ensure that the group's members remain
|
|
synchronized with the pager users. This becomes trivial
|
|
with filters. The goal is to grant access to anyone who has
|
|
a filter, plus grant access to Joe Manager, who doesn't
|
|
have a pager, but does need to access the same
|
|
resource:</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>
|
|
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))<br>
|
|
require valid-user
|
|
</code></td></tr></table></blockquote>
|
|
|
|
<p>This last may look confusing at first, so it helps to
|
|
evaluate what the search filter will look like based on who
|
|
connects, as shown below. The text in blue is the part that
|
|
is filled in using the attribute specified in the URL. The
|
|
text in red is the part that is filled in using the filter
|
|
specified in the URL. The text in green is filled in using
|
|
the information that is retrieved from the HTTP client. If
|
|
Fred User connects as <code>fuser</code>, the filter would look
|
|
like</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>(&<font color="red">(|(qpagePagerID=*)(uid=jmanager))</font>(<font color="blue">uid</font>=<font color="green">fuser</font>))</code></td></tr></table></blockquote>
|
|
|
|
<p>The above search will only succeed if <em>fuser</em> has a
|
|
pager. When Joe Manager connects as <em>jmanager</em>, the
|
|
filter looks like</p>
|
|
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>(&<font color="red">(|(qpagePagerID=*)(uid=jmanager))</font>(<font color="blue">uid</font>=<font color="green">jmanager</font>))</code></td></tr></table></blockquote>
|
|
|
|
<p>The above search will succeed whether <em>jmanager</em>
|
|
has a pager or not.</p>
|
|
</li>
|
|
</ul>
|
|
<h2><a name="usingtls">Using TLS</a></h2>
|
|
|
|
<p>To use TLS, simply set the <a href="#authldapstarttls" class="directive"><code class="directive">AuthLDAPStartTLS</code></a> to on.
|
|
Nothing else needs to be done (other than ensure that your LDAP
|
|
server is configured for TLS).</p>
|
|
<h2><a name="usingssl">Using SSL</a></h2>
|
|
|
|
<p>If <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> is linked against the
|
|
Netscape/iPlanet LDAP SDK, it will not talk to any SSL server
|
|
unless that server has a certificate signed by a known Certificate
|
|
Authority. As part of the configuration
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> needs to be told where it can find
|
|
a database containing the known CAs. This database is in the same
|
|
format as Netscape Communicator's <code>cert7.db</code>
|
|
database. The easiest way to get this file is to start up a fresh
|
|
copy of Netscape, and grab the resulting
|
|
<code>$HOME/.netscape/cert7.db</code> file.</p>
|
|
|
|
<p>To specify a secure LDAP server, use <em>ldaps://</em> in the
|
|
<a href="#authldapurl" class="directive"><code class="directive">AuthLDAPURL</code></a>
|
|
directive, instead of <em>ldap://</em>.</p>
|
|
<h2><a name="frontpage">Using Microsoft
|
|
FrontPage with mod_auth_ldap</a></h2>
|
|
|
|
<p>Normally, FrontPage uses FrontPage-web-specific user/group
|
|
files (i.e., the <code><a href="../mod/mod_auth.html">mod_auth</a></code> module) to handle all
|
|
authentication. Unfortunately, it is not possible to just
|
|
change to LDAP authentication by adding the proper directives,
|
|
because it will break the <em>Permissions</em> forms in
|
|
the FrontPage client, which attempt to modify the standard
|
|
text-based authorization files.</p>
|
|
|
|
<p>Once a FrontPage web has been created, adding LDAP
|
|
authentication to it is a matter of adding the following
|
|
directives to <em>every</em> <code>.htaccess</code> file
|
|
that gets created in the web</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code><pre>
|
|
AuthLDAPURL the url
|
|
AuthLDAPAuthoritative off
|
|
AuthLDAPFrontPageHack on
|
|
</pre></code></td></tr></table></blockquote>
|
|
|
|
<p><a href="#authldapauthoritative" class="directive"><code class="directive">AuthLDAPAuthoritative</code></a> must be
|
|
off to allow <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> to decline group
|
|
authentication so that Apache will fall back to file
|
|
authentication for checking group membership. This allows the
|
|
FrontPage-managed group file to be used.</p>
|
|
|
|
<h3><a name="howitworks">How It Works</a></h3>
|
|
|
|
<p>FrontPage restricts access to a web by adding the <code>require
|
|
valid-user</code> directive to the <code>.htaccess</code>
|
|
files. If <a href="#authldapfrontpagehack" class="directive"><code class="directive">AuthLDAPFrontPageHack</code></a> is not
|
|
on, the <code>require valid-user</code> directive will succeed for
|
|
any user who is valid <em>as far as LDAP is
|
|
concerned</em>. This means that anybody who has an entry in
|
|
the LDAP directory is considered a valid user, whereas FrontPage
|
|
considers only those people in the local user file to be
|
|
valid. The purpose of the hack is to force Apache to consult the
|
|
local user file (which is managed by FrontPage) - instead of LDAP
|
|
- when handling the <code>require valid-user</code> directive.</p>
|
|
|
|
<p>Once directives have been added as specified above,
|
|
FrontPage users will be able to perform all management
|
|
operations from the FrontPage client.</p>
|
|
|
|
|
|
<h3><a name="fpcaveats">Caveats</a></h3>
|
|
|
|
<ul>
|
|
<li>When choosing the LDAP URL, the attribute to use for
|
|
authentication should be something that will also be valid
|
|
for putting into a <code><a href="../mod/mod_auth.html">mod_auth</a></code> user file. The user ID is
|
|
ideal for this.</li>
|
|
|
|
<li>When adding users via FrontPage, FrontPage administrators
|
|
should choose usernames that already exist in the LDAP
|
|
directory (for obvious reasons). Also, the password that the
|
|
administrator enters into the form is ignored, since Apache
|
|
will actually be authenticating against the password in the
|
|
LDAP database, and not against the password in the local user
|
|
file. This could cause confusion for web administrators.</li>
|
|
|
|
<li>Apache must be compiled with <code><a href="../mod/mod_auth.html">mod_auth</a></code> in order to
|
|
use FrontPage support. This is because Apache will still use
|
|
the <code><a href="../mod/mod_auth.html">mod_auth</a></code> group file for determine the extent of a
|
|
user's access to the FrontPage web.</li>
|
|
|
|
<li>The directives must be put in the <code>.htaccess</code>
|
|
files. Attempting to put them inside <a href="../mod/core.html#location" class="directive"><code class="directive"><Location></code></a> or <a href="../mod/core.html#directory" class="directive"><code class="directive"><Directory></code></a> directives won't work. This
|
|
is because <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> has to be able to grab
|
|
the <a href="../mod/mod_auth.html#authuserfile" class="directive"><code class="directive">AuthUserFile</code></a>
|
|
directive that is found in FrontPage <code>.htaccess</code>
|
|
files so that it knows where to look for the valid user list. If
|
|
the <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> directives aren't in the same
|
|
<code>.htaccess</code> file as the FrontPage directives, then
|
|
the hack won't work, because <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will
|
|
never get a chance to process the <code>.htaccess</code> file,
|
|
and won't be able to find the FrontPage-managed user file.</li>
|
|
</ul>
|
|
|
|
<hr><h2><a name="AuthLDAPAuthoritative">AuthLDAPAuthoritative</a> <a name="authldapauthoritative">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPAuthoritative on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPAuthoritative on</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>Set to <code>off</code> if this module should let other
|
|
authentication modules attempt to authenticate the user, should
|
|
authentication with this module fail. Control is only passed on
|
|
to lower modules if there is no DN or rule that matches the
|
|
supplied user name (as passed by the client).</p>
|
|
<hr><h2><a name="AuthLDAPBindDN">AuthLDAPBindDN</a> <a name="authldapbinddn">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPBindDN <em>distinguished-name</em></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>An optional DN used to bind to the server when searching for
|
|
entries. If not provided, <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will use
|
|
an anonymous bind.</p>
|
|
<hr><h2><a name="AuthLDAPBindPassword">AuthLDAPBindPassword</a> <a name="authldapbindpassword">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPBindPassword <em>password</em></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>A bind password to use in conjunction with the bind DN. Note
|
|
that the bind password is probably sensitive data, and should be
|
|
properly protected. You should only use the <a href="#authldapbinddn" class="directive"><code class="directive">AuthLDAPBindDN</code></a> and <a href="#authldapbindpassword" class="directive"><code class="directive">AuthLDAPBindPassword</code></a> if you
|
|
absolutely need them to search the directory.</p>
|
|
<hr><h2><a name="AuthLDAPCompareDNOnServer">AuthLDAPCompareDNOnServer</a> <a name="authldapcomparednonserver">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPCompareDNOnServer on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPCompareDNOnServer on</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>When set, <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will use the LDAP
|
|
server to compare the DNs. This is the only foolproof way to
|
|
compare DNs. <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will search the
|
|
directory for the DN specified with the <a href="#reqdn"><code>require dn</code></a> directive, then,
|
|
retrieve the DN and compare it with the DN retrieved from the user
|
|
entry. If this directive is not set,
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> simply does a string comparison. It
|
|
is possible to get false negatives with this approach, but it is
|
|
much faster. Note the <code><a href="../mod/mod_ldap.html">mod_ldap</a></code> cache can speed up
|
|
DN comparison in most situations.</p>
|
|
<hr><h2><a name="AuthLDAPDereferenceAliases">AuthLDAPDereferenceAliases</a> <a name="authldapdereferencealiases">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPDereferenceAliases never|searching|finding|always</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPDereferenceAliases Always</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>This directive specifies when <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will
|
|
de-reference aliases during LDAP operations. The default is
|
|
<code>always</code>.</p>
|
|
<hr><h2><a name="AuthLDAPEnabled">AuthLDAPEnabled</a> <a name="authldapenabled">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td> AuthLDAPEnabled on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPEnabled on</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>Set to <code>off</code> to disable
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> in certain directories. This is
|
|
useful if you have <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> enabled at or
|
|
near the top of your tree, but want to disable it completely in
|
|
certain locations.</p>
|
|
<hr><h2><a name="AuthLDAPFrontPageHack">AuthLDAPFrontPageHack</a> <a name="authldapfrontpagehack">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPFrontPageHack on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPFronPageHack off</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>See the section on <a href="#frontpage">using Microsoft
|
|
FrontPage</a> with <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code>.</p>
|
|
<hr><h2><a name="AuthLDAPGroupAttribute">AuthLDAPGroupAttribute</a> <a name="authldapgroupattribute">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPGroupAttribute <em>attribute</em></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>This directive specifies which LDAP attributes are used to
|
|
check for group membership. Multiple attributes can be used by
|
|
specifying this directive multiple times. If not specified,
|
|
then <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> uses the <code>member</code> and
|
|
<code>uniquemember</code> attributes.</p>
|
|
<hr><h2><a name="AuthLDAPGroupAttributeIsDN">AuthLDAPGroupAttributeIsDN</a> <a name="authldapgroupattributeisdn">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPGroupAttributeIsDN on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPGroupAttributeIsDN on</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>When set <code>on</code>, this directive says to use the
|
|
distinguished name of the client username when checking for group
|
|
membership. Otherwise, the username will be used. For example,
|
|
assume that the client sent the username <code>bjenson</code>,
|
|
which corresponds to the LDAP DN <code>cn=Babs Jenson,
|
|
o=Airius</code>. If this directive is set,
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will check if the group has
|
|
<code>cn=Babs Jenson, o=Airius</code> as a member. If this
|
|
directive is not set, then <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will
|
|
check if the group has <code>bjenson</code> as a member.</p>
|
|
<hr><h2><a name="AuthLDAPRemoteUserIsDN">AuthLDAPRemoteUserIsDN</a> <a name="authldapremoteuserisdn">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPRemoteUserIsDN on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPUserIsDN off</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>If this directive is set to on, the value of the
|
|
<code>REMOTE_USER</code> environment variable will be set to the full
|
|
distinguished name of the authenticated user, rather than just
|
|
the username that was passed by the client. It is turned off by
|
|
default.</p>
|
|
<hr><h2><a name="AuthLDAPStartTLS directive">AuthLDAPStartTLS directive</a> <a name="authldapstarttls directive">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPStartTLS on|off</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Default" class="help">Default:
|
|
</a></td><td><code>AuthLDAPStartTLS off</code></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>If this directive is set to <code>on</code>,
|
|
<code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will start a secure TLS session
|
|
after connecting to the LDAP server. This requires your LDAP
|
|
server to support TLS.</p>
|
|
<hr><h2><a name="AuthLDAPUrl">AuthLDAPUrl</a> <a name="authldapurl">Directive</a></h2><table cellpadding="1" cellspacing="0" border="0" bgcolor="#cccccc"><tr><td><table bgcolor="#ffffff"><tr><td nowrap="nowrap"><strong>Description:
|
|
</strong></td><td></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Syntax" class="help">Syntax:
|
|
</a></td><td>AuthLDAPUrl <em>url</em></td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Context" class="help">Context:
|
|
</a></td><td>directory, .htaccess</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Override" class="help">Override:
|
|
</a></td><td>AuthConfig</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Status" class="help">Status:
|
|
</a></td><td>experimental</td></tr><tr><td nowrap="nowrap"><a href="directive-dict.html#Module" class="help">Module:
|
|
</a></td><td>mod_auth_ldap</td></tr></table></td></tr></table>
|
|
<p>An RFC 2255 URL which specifies the LDAP search parameters
|
|
to use. The syntax of the URL is</p>
|
|
<blockquote><table cellpadding="10"><tr><td bgcolor="#eeeeee"><code>ldap://host:port/basedn?attribute?scope?filter</code></td></tr></table></blockquote>
|
|
|
|
<dl>
|
|
<dt>ldap</dt>
|
|
|
|
<dd>For regular ldap, use the
|
|
string <code>ldap</code>. For secure LDAP, use <code>ldaps</code>
|
|
instead. Secure LDAP is only available if Apache was linked
|
|
to an LDAP library with SSL support.</dd>
|
|
|
|
<dt>host:port</dt>
|
|
|
|
<dd>
|
|
<p>The name/port of the ldap server (defaults to
|
|
<code>localhost:389</code> for <code>ldap</code>, and
|
|
<code>localhost:636</code> for <code>ldaps</code>). To
|
|
specify multiple, redundant LDAP servers, just list all
|
|
servers, separated by spaces. <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code>
|
|
will try connecting to each server in turn, until it makes a
|
|
successful connection.</p>
|
|
|
|
<p>Once a connection has been made to a server, that
|
|
connection remains active for the life of the
|
|
<code>httpd</code> process, or until the LDAP server goes
|
|
down.</p>
|
|
|
|
<p>If the LDAP server goes down and breaks an existing
|
|
connection, <code><a href="../mod/mod_auth_ldap.html">mod_auth_ldap</a></code> will attempt to
|
|
re-connect, starting with the primary server, and trying
|
|
each redundant server in turn. Note that this is different
|
|
than a true round-robin search.</p>
|
|
</dd>
|
|
|
|
<dt>basedn</dt>
|
|
|
|
<dd>The DN of the branch of the
|
|
directory where all searches should start from. At the very
|
|
least, this must be the top of your directory tree, but
|
|
could also specify a subtree in the directory.</dd>
|
|
|
|
<dt>attribute</dt>
|
|
|
|
<dd>The attribute to search for.
|
|
Although RFC 2255 allows a comma-separated list of
|
|
attributes, only the first attribute will be used, no
|
|
matter how many are provided. If no attributes are
|
|
provided, the default is to use <code>uid</code>. It's a good
|
|
idea to choose an attribute that will be unique across all
|
|
entries in the subtree you will be using.</dd>
|
|
|
|
<dt>scope</dt>
|
|
|
|
<dd>The scope of the search. Can be either <code>one</code> or
|
|
<code>sub</code>. Note that a scope of <code>base</code> is
|
|
also supported by RFC 2255, but is not supported by this
|
|
module. If the scope is not provided, or if <code>base</code> scope
|
|
is specified, the default is to use a scope of
|
|
<code>sub</code>.</dd>
|
|
|
|
<dt>filter</dt>
|
|
|
|
<dd>A valid LDAP search filter. If
|
|
not provided, defaults to <code>(objectClass=*)</code>, which
|
|
will search for all objects in the tree. Filters are
|
|
limited to approximately 8000 characters (the definition of
|
|
<code>MAX_STRING_LEN</code> in the Apache source code). This
|
|
should be than sufficient for any application.</dd>
|
|
</dl>
|
|
|
|
<p>When doing searches, the attribute, filter and username passed
|
|
by the HTTP client are combined to create a search filter that
|
|
looks like
|
|
<code>(&(<em>filter</em>)(<em>attribute</em>=<em>username</em>))</code>.</p>
|
|
|
|
<p>For example, consider an URL of
|
|
<code>ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*)</code>. When
|
|
a client attempts to connect using a username of <code>Babs
|
|
Jenson</code>, the resulting search filter will be
|
|
<code>(&(posixid=*)(cn=Babs Jenson))</code>.</p>
|
|
|
|
<p>See above for examples of <a href="#authldapurl" class="directive"><code class="directive">AuthLDAPURL</code></a> URLs.</p>
|
|
<hr></blockquote><h3 align="center">Apache HTTP Server Version 2.0</h3><a href="./"><img src="../images/index.gif" alt="Index"></a><a href="../"><img src="../images/home.gif" alt="Home"></a></body></html> |