mirror of
https://github.com/apache/httpd.git
synced 2025-10-22 23:12:44 +03:00
22c671d0e0
it when the httpd-ldap project was created. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96488 13f79535-47bb-0310-9956-ffa450edef68
990 lines
37 KiB
HTML
990 lines
37 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
|
|
<title>Apache module mod_ldap</title>
|
|
<!--
|
|
Copyright (C) 2000,2001 Dave Carrigan <dave@rudedog.org>
|
|
Copyright (C) 2001-2002 The Apache Software Foundation
|
|
-->
|
|
</head>
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
|
|
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
|
|
vlink="#000080" alink="#FF0000">
|
|
<!--#include virtual="header.html" -->
|
|
|
|
<h1 align="CENTER">Module mod_auth_ldap</h1>
|
|
|
|
<p>This is an authentication module that allows Apache to
|
|
authenticate HTTP clients using user entries in an LDAP
|
|
directory.</p>
|
|
|
|
<p><a href="module-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="module-dict.html#SourceFile"
|
|
rel="Help"><strong>Source File:</strong></a> util_ldap.c<br />
|
|
<a href="module-dict.html#ModuleIdentifier"
|
|
rel="Help"><strong>Module Identifier:</strong></a>
|
|
ldap_module<br />
|
|
<a href="module-dict.html#Compatibility"
|
|
rel="Help"><strong>Compatibility:</strong></a> Available in
|
|
Apache 2.0 and later.</p>
|
|
|
|
<h2>Summary</h2>
|
|
|
|
<p>mod_auth_ldap 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">AuthLDAPStartTLS</a></li>
|
|
|
|
<li><a href="#AuthLDAPUrl">AuthLDAPUrl</a></li>
|
|
</ul>
|
|
|
|
<h2>Contents</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
|
|
mod_auth_ldap</a>
|
|
|
|
<ul>
|
|
<li><a href="#howitworks">How It Works</a></li>
|
|
|
|
<li><a href="#fpcaveats">Caveats</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a id="operation" name="operation">Operation</a></h2>
|
|
|
|
<p>There are two phases in granting access to a user. The first
|
|
phase is authentication, in which mod_auth_ldap verifies that
|
|
the user's credentials are valid. This also called the
|
|
<em><b>search/bind</b></em> phase. The second phase is
|
|
authorization, in which mod_auth_ldap determines if the
|
|
authenticated user is allowed access to the resource in
|
|
question. This is also known as the <em><b>compare</b></em>
|
|
phase.</p>
|
|
|
|
<h3><a id="authenphase" name="authenphase">The Authentication
|
|
Phase</a></h3>
|
|
|
|
<p>During the authentication phase, mod_auth_ldap searches for
|
|
an entry in the directory that matches the username that the
|
|
HTTP client passes. If a single unique match is found, then
|
|
mod_auth_ldap 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"><tt>AuthLDAPURL</tt></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 border="0" bgcolor="#ffffff">
|
|
<tr valign="top">
|
|
<td colspan="1" align="left"><a
|
|
href="#AuthLDAPURL">AuthLDAPURL</a> </td>
|
|
|
|
<td colspan="1" align="left">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 valign="top">
|
|
<td colspan="1" align="left"><a
|
|
href="#AuthLDAPBindDN">AuthLDAPBindDN</a> </td>
|
|
|
|
<td colspan="1" align="left">An optional DN to bind with
|
|
during the search phase.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left"><a
|
|
href="#AuthLDAPBindPassword">AuthLDAPBindPassword</a> </td>
|
|
|
|
<td colspan="1" align="left">An optional password to bind
|
|
with during the search phase.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3><a id="authorphase" name="authorphase">The Authorization
|
|
Phase</a></h3>
|
|
|
|
<p>During the authorization phase, mod_auth_ldap attempts to
|
|
determine if the user is authorized to access the resource.
|
|
Many of these checks require mod_auth_ldap to do a compare
|
|
operation on the LDAP server. This is why this phase is often
|
|
referred to as the compare phase. mod_auth_ldap accepts the
|
|
following <a href="#requiredirectives"><tt>require</tt>
|
|
directives</a> to determine if the credentials are
|
|
acceptable:</p>
|
|
|
|
<ul>
|
|
<li>Grant access if there is a <a href="#requser"><tt>require
|
|
valid-user</tt></a> directive.</li>
|
|
|
|
<li>Grant access if there is a <a
|
|
href="#reqgroup"><tt>require user</tt></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"><tt>require
|
|
dn</tt></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"><tt>require group</tt></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>mod_auth_ldap uses the following directives during the
|
|
compare phase:</p>
|
|
|
|
<table border="0" bgcolor="#ffffff">
|
|
<tr>
|
|
<td><a href="#AuthLDAPURL"><tt>AuthLDAPURL</tt></a> </td>
|
|
|
|
<td colspan="1" align="left">The attribute specified in the
|
|
URL is used in compare operations for the <tt>require
|
|
user</tt> operation.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a
|
|
href="#AuthLDAPCompareDNOnServer"><tt>AuthLDAPCompareDNOnServer</tt></a>
|
|
</td>
|
|
|
|
<td colspan="1" align="left">Determines the behavior of the
|
|
<tt>require dn</tt> directive.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a
|
|
href="#AuthLDAPGroupAttribute"><tt>AuthLDAPGroupAttribute</tt></a>
|
|
</td>
|
|
|
|
<td colspan="1" align="left">Determines the attribute to
|
|
use for comparisons in the <tt>require group</tt>
|
|
directive.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a
|
|
href="#AuthLDAPGroupAttributeIsDN"><tt>AuthLDAPGroupAttributeIsDN</tt></a>
|
|
</td>
|
|
|
|
<td colspan="1" align="left">Specifies whether to use the
|
|
user DN or the username when doing comparisons for the
|
|
<tt>require group</tt> directive.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2><a id="requiredirectives" name="requiredirectives">The
|
|
require Directives</a></h2>
|
|
|
|
<p>Apache's <tt>require</tt> directives are used during the
|
|
authorization phase to ensure that a user is allowed to access
|
|
a resource.</p>
|
|
|
|
<h3><a id="reqvaliduser" name="reqvaliduser">require
|
|
valid-user</a></h3>
|
|
|
|
<p>If this directive exists, mod_auth_ldap grants access to any
|
|
user that has successfully authenticated during the search/bind
|
|
phase.</p>
|
|
|
|
<h3><a id="requser" name="requser">require user</a></h3>
|
|
|
|
<p>The <tt>require user</tt> directive specifies what usernames
|
|
can access the resource. Once mod_auth_ldap has retrieved a
|
|
unique DN from the directory, it does an LDAP compare operation
|
|
using the username specified in the <tt>require user</tt> 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 <tt>require user</tt> directives, with one user per
|
|
line. For example, with a <tt>AuthLDAPURL</tt> of
|
|
<i>ldap://ldap/o=Airius?cn</i> (i.e., <tt>cn</tt> is used for
|
|
searches), the following require directives could be used to
|
|
restrict access:</p>
|
|
<pre>
|
|
require user Barbara Jenson
|
|
require user Fred User
|
|
require user Joe Manager
|
|
</pre>
|
|
|
|
<p>Because of the way that mod_auth_ldap handles this
|
|
directive, Barbara Jenson could sign on as <i>Barbara
|
|
Jenson</i>, <i>Babs Jenson</i> or any other <tt>cn</tt> that
|
|
she has in her LDAP entry. Only the single <tt>require
|
|
user</tt> line is needed to support all values of the attribute
|
|
in the user's entry.</p>
|
|
|
|
<p>If the <tt>uid</tt> attribute was used instead of the
|
|
<tt>cn</tt> attribute in the URL above, the above three lines
|
|
could be condensed to</p>
|
|
<pre>
|
|
require user bjenson fuser jmanager
|
|
</pre>
|
|
|
|
<h3><a id="reqgroup" 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>
|
|
<pre>
|
|
dn: cn=Administrators, o=Airius
|
|
objectClass: groupOfUniqueNames
|
|
uniqueMember: cn=Barbara Jenson, o=Airius
|
|
uniqueMember: cn=Fred User, o=Airius
|
|
</pre>
|
|
|
|
<p>The following directive would grant access to both Fred and
|
|
Barbara:</p>
|
|
<pre>
|
|
require group cn=Administrators, o=Airius
|
|
</pre>
|
|
|
|
<p>Behavior of this directive is modified by the <a
|
|
href="#AuthLDAPGroupAttribute"><tt>AuthLDAPGroupAttribute</tt></a>
|
|
and <a
|
|
href="#AuthLDAPGroupAttributeIsDN"><tt>AuthLDAPGroupAttributeIsDN</tt></a>
|
|
directives.</p>
|
|
|
|
<h3><a id="reqdn" name="reqdn">require dn</a></h3>
|
|
|
|
<p>The <tt>require dn</tt> 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 <tt>require dn</tt>, then
|
|
authorization is granted.</p>
|
|
|
|
<p>The following directive would grant access to a specific
|
|
DN:</p>
|
|
<pre>
|
|
require dn cn=Barbara Jenson, o=Airius
|
|
</pre>
|
|
|
|
<p>Behavior of this directive is modified by the <a
|
|
href="#AuthLDAPCompareDNOnServer"><tt>AuthLDAPCompareDNOnServer</tt></a>
|
|
directive.</p>
|
|
|
|
<h2><a id="examples" name="examples">Examples</a></h2>
|
|
|
|
<ul>
|
|
<li>
|
|
Grant access to anyone who exists in the LDAP directory,
|
|
using their UID for searches.
|
|
<pre>
|
|
AuthLDAPURL ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)
|
|
require valid-user
|
|
</pre>
|
|
</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.
|
|
<pre>
|
|
AuthLDAPURL ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius
|
|
require valid-user
|
|
</pre>
|
|
</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 <tt>cn</tt>, because a search on <tt>cn</tt>
|
|
<em><b>must</b></em> 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 <tt>uid</tt>.
|
|
<pre>
|
|
AuthLDAPURL ldap://ldap.airius.com/ou=People, o=Airius?cn
|
|
require valid-user
|
|
</pre>
|
|
</li>
|
|
|
|
<li>
|
|
Grant access to anybody in the Administrators group. The
|
|
users must authenticate using their UID.
|
|
<pre>
|
|
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid
|
|
require group cn=Administrators, o=Airius
|
|
</pre>
|
|
</li>
|
|
|
|
<li>
|
|
The next example assumes that everyone at Airius who
|
|
carries an alphanumeric pager will have an LDAP attribute
|
|
of <tt>qpagePagerID</tt>. The example will grant access
|
|
only to people (authenticated via their UID) who have
|
|
alphanumeric pagers:
|
|
<pre>
|
|
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)
|
|
require valid-user
|
|
</pre>
|
|
</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>
|
|
<pre>
|
|
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))
|
|
require valid-user
|
|
</pre>
|
|
|
|
<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 <i>fuser</i>, the filter would look
|
|
like</p>
|
|
|
|
<p><tt>(&<font
|
|
color="red">(|(qpagePagerID=*)(uid=jmanager))</font>(<font
|
|
color="blue">uid</font>=<font
|
|
color="green">fuser</font>))</tt></p>
|
|
|
|
<p>The above search will only succeed if <i>fuser</i> has a
|
|
pager. When Joe Manager connects as <i>jmanager</i>, the
|
|
filter looks like</p>
|
|
|
|
<p><tt>(&<font
|
|
color="red">(|(qpagePagerID=*)(uid=jmanager))</font>(<font
|
|
color="blue">uid</font>=<font
|
|
color="green">jmanager</font>))</tt></p>
|
|
|
|
<p>The above search will succeed whether <i>jmanager</i>
|
|
has a pager or not.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a id="usingtls" name="usingtls">Using TLS</a></h2>
|
|
|
|
<p>To use TLS, simply set the <tt>AuthLDAPStartTLS</tt> to on.
|
|
Nothing else needs to be done (other than ensure that your LDAP
|
|
server is configured for TLS).</p>
|
|
|
|
<h2><a id="usingssl" name="usingssl">Using SSL</a></h2>
|
|
|
|
<p>If mod_auth_ldap 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 mod_auth_ldap 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 <tt>cert7.db</tt>
|
|
database. The easiest way to get this file is to start up a
|
|
fresh copy of Netscape, and grab the resulting
|
|
<tt>$HOME/.netscape/cert7.db</tt> file.</p>
|
|
|
|
<p>To specify a secure LDAP server, use <i>ldaps://</i> in the
|
|
<tt>AuthLDAPURL</tt> directive, instead of <i>ldap://</i>.</p>
|
|
|
|
<h2><a id="frontpage" name="frontpage">Using Microsoft
|
|
FrontPage with mod_auth_ldap</a></h2>
|
|
|
|
<p>Normally, FrontPage uses FrontPage-web-specific user/group
|
|
files (i.e., the <i>mod_auth</i> 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><b>Permissions</b></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><b>every</b></em> <tt>.htaccess</tt> file
|
|
that gets created in the web</p>
|
|
<pre>
|
|
AuthLDAPURL the url
|
|
AuthLDAPAuthoritative off
|
|
AuthLDAPFrontPageHack on
|
|
</pre>
|
|
|
|
<p><tt>AuthLDAPAuthoritative</tt> must be off to allow
|
|
mod_auth_ldap 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 id="howitworks" name="howitworks">How It Works</a></h3>
|
|
|
|
<p>FrontPage restricts access to a web by adding the
|
|
<tt>require valid-user</tt> directive to the <tt>.htaccess</tt>
|
|
files. If <tt>AuthLDAPFrontPageHack</tt> is not on, the
|
|
<tt>require valid-user</tt> directive will succeed for any user
|
|
who is valid <em><b>as far as LDAP is concerned</b></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
|
|
<tt>require valid-user</tt> 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 id="fpcaveats" 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 <i>mod_auth</i> 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 <i>mod_auth</i> in order to
|
|
use FrontPage support. This is because Apache will still use
|
|
the <i>mod_auth</i> group file for determine the extent of a
|
|
user's access to the FrontPage web.</li>
|
|
|
|
<li>The directives must be put in the <tt>.htaccess</tt>
|
|
files. Attempting to put them inside
|
|
<tt><Location></tt> or <tt><Directory></tt>
|
|
directives won't work. This is because mod_auth_ldap has to
|
|
be able to grab the <tt>AuthUserFile</tt> directive that is
|
|
found in FrontPage <tt>.htaccess</tt> files so that it knows
|
|
where to look for the valid user list. If the mod_auth_ldap
|
|
directives aren't in the same <tt>.htaccess</tt> file as the
|
|
FrontPage directives, then the hack won't work, because
|
|
mod_auth_ldap will never get a chance to process the
|
|
<tt>.htaccess</tt> file, and won't be able to find the
|
|
FrontPage-managed user file.</li>
|
|
</ul>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPAuthoritative"
|
|
name="AuthLDAPAuthoritative">AuthLDAPAuthoritative
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPAuthoritative
|
|
on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a>
|
|
<code>AuthLDAPAuthoritative on</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>Set to <i>off</i> 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 id="AuthLDAPBindDN" name="AuthLDAPBindDN">AuthLDAPBindDN
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPBindDN
|
|
<em>distinguished-name</em><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>An optional DN used to bind to the server when searching for
|
|
entries. If not provided, mod_auth_ldap will use an anonymous
|
|
bind.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPBindPassword"
|
|
name="AuthLDAPBindPassword">AuthLDAPBindPassword
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPBindPassword
|
|
<em>password</em><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<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"><tt>AuthLDAPBindDN</tt></a> and <a
|
|
href="#AuthLDAPBindPassword"><tt>AuthLDAPBindPassword</tt></a>
|
|
if you absolutely need them to search the directory.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPCompareDNOnServer"
|
|
name="AuthLDAPCompareDNOnServer">AuthLDAPCompareDNOnServer
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a>
|
|
AuthLDAPCompareDNOnServer on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a>
|
|
<code>AuthLDAPCompareDNOnServer on</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>When set, mod_auth_ldap will use the LDAP server to compare
|
|
the DNs. This is the only foolproof way to compare DNs.
|
|
mod_auth_ldap will search the directory for the DN specified
|
|
with the <a href="#reqdn"><tt>require dn</tt></a> directive,
|
|
then, retrieve the DN and compare it with the DN retrieved from
|
|
the user entry. If this directive is not set, mod_auth_ldap
|
|
simply does a string comparison. It is possible to get false
|
|
negatives with this approach, but it is much faster. Note the
|
|
mod_ldap cache can speed up DN comparison in most
|
|
situations.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPDereferenceAliases"
|
|
name="AuthLDAPDereferenceAliases">AuthLDAPDereferenceAliases
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a>
|
|
AuthLDAPDereferenceAliases never|searching|finding|always<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a>
|
|
<code>AuthLDAPDereferenceAliases Always</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>This directive specifies when mod_auth_ldap will
|
|
de-reference aliases during LDAP operations. The default is
|
|
<i>always</i>.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPEnabled"
|
|
name="AuthLDAPEnabled">AuthLDAPEnabled directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPEnabled
|
|
on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a> <code>AuthLDAPEnabled
|
|
on</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>Set to <i>off</i> to disable mod_auth_ldap in certain
|
|
directories. This is useful if you have mod_auth_ldap enabled
|
|
at or near the top of your tree, but want to disable it
|
|
completely in certain locations.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPFrontPageHack"
|
|
name="AuthLDAPFrontPageHack">AuthLDAPFrontPageHack
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPFrontPageHack
|
|
on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a>
|
|
<code>AuthLDAPFronPageHack off</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>See the section on <a href="#frontpage">using Microsoft
|
|
FrontPage</a> with mod_auth_ldap.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPGroupAttribute"
|
|
name="AuthLDAPGroupAttribute">AuthLDAPGroupAttribute
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPGroupAttribute
|
|
<em>attribute</em><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<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 mod_auth_ldap uses the <tt>member</tt> and
|
|
<tt>uniquemember</tt> attributes.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPGroupAttributeIsDN"
|
|
name="AuthLDAPGroupAttributeIsDN">AuthLDAPGroupAttributeIsDN
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a>
|
|
AuthLDAPGroupAttributeIsDN on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a>
|
|
<code>AuthLDAPGroupAttributeIsDN on</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>When set, 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 <i>bjenson</i>, which corresponds
|
|
to the LDAP DN <i>cn=Babs Jenson, o=Airius</i>. If this
|
|
directive is set, mod_auth_ldap will check if the group has
|
|
<i>cn=Babs Jenson, o=Airius</i> as a member. If this directive
|
|
is not set, then mod_auth_ldap will check if the group has
|
|
<i>bjenson</i> as a member.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPRemoteUserIsDN"
|
|
name="AuthLDAPRemoteUserIsDN">AuthLDAPRemoteUserIsDN
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPRemoteUserIsDN
|
|
on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a> <code>AuthLDAPUserIsDN
|
|
off</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>If this directive is set to on, the value of the
|
|
<i>REMOTE_USER</i> 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 id="AuthLDAPStartTLS"
|
|
name="AuthLDAPStartTLS">AuthLDAPStartTLS directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPStartTLS
|
|
on|off<br />
|
|
<a href="directive-dict.html#Default"
|
|
rel="Help"><strong>Default:</strong></a> <code>AuthLDAPStartTLS
|
|
off</code><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>If this directive is set to on, mod_auth_ldap will start a
|
|
secure TLS session after connecting to the LDAP server. This
|
|
requires your LDAP server to support TLS.</p>
|
|
<hr />
|
|
|
|
<h2><a id="AuthLDAPUrl" name="AuthLDAPUrl">AuthLDAPUrl
|
|
directive</a></h2>
|
|
|
|
<p><a href="directive-dict.html#Syntax"
|
|
rel="Help"><strong>Syntax:</strong></a> AuthLDAPUrl
|
|
<em>url</em><br />
|
|
<a href="directive-dict.html#Context"
|
|
rel="Help"><strong>Context:</strong></a> directory,
|
|
.htaccess<br />
|
|
<a href="directive-dict.html#Override"
|
|
rel="Help"><strong>Override:</strong></a> AuthConfig<br />
|
|
<a href="directive-dict.html#Status"
|
|
rel="Help"><strong>Status:</strong></a> Extension<br />
|
|
<a href="directive-dict.html#Module"
|
|
rel="Help"><strong>Module:</strong></a> mod_auth_ldap</p>
|
|
|
|
<p>An RFC 2255 URL which specifies the LDAP search parameters
|
|
to use. The syntax of the URL is</p>
|
|
<pre>
|
|
ldap://host:port/basedn?attribute?scope?filter
|
|
</pre>
|
|
|
|
<table border="0" bgcolor="#ffffff">
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">ldap</td>
|
|
|
|
<td colspan="1" align="left">For regular ldap, use the
|
|
string <i>ldap</i>. For secure LDAP, use <i>ldaps</i>
|
|
instead. Secure LDAP is only available if Apache was linked
|
|
to an LDAP library with SSL support.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">host:port</td>
|
|
|
|
<td colspan="1" align="left">
|
|
<p>The name/port of the ldap server (defaults to
|
|
<i>localhost:389</i> for <i>ldap</i>, and
|
|
<i>localhost:636</i> for <i>ldaps</i>). To specify
|
|
multiple, redundant LDAP servers, just list all servers,
|
|
separated by spaces. mod_auth_ldap 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
|
|
<i>httpd</i> process, or until the LDAP server goes
|
|
down.</p>
|
|
|
|
<p>If the LDAP server goes down and breaks an existing
|
|
connection, mod_auth_ldap 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>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">basedn</td>
|
|
|
|
<td colspan="1" align="left">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.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">attribute</td>
|
|
|
|
<td colspan="1" align="left">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 <tt>uid</tt>. It's a good
|
|
idea to choose an attribute that will be unique across all
|
|
entries in the subtree you will be using.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">scope</td>
|
|
|
|
<td colspan="1" align="left">The scope of the search. Can
|
|
be either <i>one</i> or <i>sub</i>. Note that a scope of
|
|
<i>base</i> is also supported by RFC 2255, but is not
|
|
supported by this module. If the scope is not provided, or
|
|
if <i>base</i> scope is specified, the default is to use a
|
|
scope of <i>sub</i>.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">filter</td>
|
|
|
|
<td colspan="1" align="left">A valid LDAP search filter. If
|
|
not provided, defaults to <tt>(objectClass=*)</tt>, which
|
|
will search for all objects in the tree. Filters are
|
|
limited to approximately 8000 characters (the definition of
|
|
<i>MAX_STRING_LEN</i> in the Apache source code). This
|
|
should be than sufficient for any application.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>When doing searches, the attribute, filter and username
|
|
passed by the HTTP client are combined to create a search
|
|
filter that looks like
|
|
<tt>(&(<i>filter</i>)(<i>attribute</i>=<i>username</i>))</tt>.</p>
|
|
|
|
<p>For example, consider an URL of
|
|
<i>ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*)</i>. When
|
|
a client attempts to connect using a username of <i>Babs
|
|
Jenson</i>, the resulting search filter will be
|
|
<tt>(&(posixid=*)(cn=Babs Jenson))</tt>.</p>
|
|
|
|
<p>See above for examples of <a
|
|
href="#AuthLDAPURL"><tt>AuthLDAPURL</tt></a> URLs.</p>
|
|
<!--#include virtual="footer.html" -->
|
|
</body>
|
|
</html>
|
|
|