<p>The following directive would grant access to anyone with
the attribute employeeType = active</p>
- <pre class="prettyprint lang-config">Require ldap-attribute employeeType=active</pre>
+ <pre class="prettyprint lang-config">Require ldap-attribute "employeeType=active"</pre>
<p>Multiple attribute/value pairs can be specified on the same line
<p>The following directive would grant access to anyone with
the city attribute equal to "San Jose" or status equal to "Active"</p>
- <pre class="prettyprint lang-config">Require ldap-attribute city="San Jose" status=active</pre>
+ <pre class="prettyprint lang-config">Require ldap-attribute city="San Jose" "status=active"</pre>
<p>The following directive would grant access to anyone having a cell phone
and is in the marketing department</p>
- <pre class="prettyprint lang-config">Require ldap-filter &(cell=*)(department=marketing)</pre>
+ <pre class="prettyprint lang-config">Require ldap-filter "&(cell=*)(department=marketing)"</pre>
<p>The difference between the <code>Require ldap-filter</code> directive and the
<div class="directive-section"><h2><a name="AuthLDAPBindAuthoritative" id="AuthLDAPBindAuthoritative">AuthLDAPBindAuthoritative</a> <a name="authldapbindauthoritative" id="authldapbindauthoritative">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Determines if other authentication providers are used when a user can be mapped to a DN but the server cannot successfully bind with the user's credentials.</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPBindAuthoritative<em>off|on</em></code></td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPBindAuthoritative off|on</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>AuthLDAPBindAuthoritative on</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>AuthConfig</td></tr>
<p>By default, subsequent authentication providers are only queried if a
user cannot be mapped to a DN, but not if the user can be mapped to a DN and their
password cannot be verified with an LDAP bind.
- If <code class="directive"><a href="#authldapbindauthoritative">AuthLDAPBindAuthoritative</a></code>
+ If <code class="directive">AuthLDAPBindAuthoritative</code>
is set to <em>off</em>, other configured authentication modules will have
a chance to validate the user if the LDAP bind (with the current user's credentials)
fails for any reason.</p>
</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 <code class="directive"><a href="#authldapbinddn">AuthLDAPBindDN</a></code> and <code class="directive"><a href="#authldapbindpassword">AuthLDAPBindPassword</a></code> if you
+ properly protected. You should only use the <code class="directive"><a href="#authldapbinddn">AuthLDAPBindDN</a></code> and <code class="directive">AuthLDAPBindPassword</code> if you
absolutely need them to search the directory.</p>
<p>If the value begins with exec: the resulting command will be
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Determines if the server does the initial DN lookup using the basic authentication users'
own username, instead of anonymously or with hard-coded credentials for the server</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPInitialBindAsUser <em>off|on</em></code></td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPInitialBindAsUser off|on</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>AuthLDAPInitialBindAsUser off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>AuthConfig</td></tr>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Specifies the transformation of the basic authentication username to be used when binding to the LDAP server
to perform a DN lookup</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPInitialBindPattern<em><var>regex</var> <var>substitution</var></em></code></td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>AuthLDAPInitialBindPattern <em><var>regex</var> <var>substitution</var></em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>AuthConfig</td></tr>
value of the attribute specified. Make sure that this attribute is
included in the list of attributes in the AuthLDAPUrl definition,
otherwise this directive will have no effect. This directive, if
- present, takes precedence over AuthLDAPRemoteUserIsDN. This
+ present, takes precedence over <code class="directive"><a href="#authldapremoteuserisdn">AuthLDAPRemoteUserIsDN</a></code>. This
directive is useful should you want people to log into a website
using an email address, but a backend application expects the
username as a userid.</p>
</table>
<p>An LDAP group object may contain members that are users and
members that are groups (called nested or sub groups). The
- <code>AuthLDAPSubGroupAttribute</code> directive identifies the
- labels of group members and the <code>AuthLDAPGroupAttribute</code>
+ <code class="directive">AuthLDAPSubGroupAttribute</code> directive identifies the
+ labels of group members and the <code class="directive"><a href="#authldapgroupattribute">AuthLDAPGroupAttribute</a></code>
directive identifies the labels of the user members. Multiple
attributes can be used by specifying this directive multiple times.
If not specified, then <code class="module"><a href="../mod/mod_authnz_ldap.html">mod_authnz_ldap</a></code> uses the
</table>
<p>An LDAP group object may contain members that are users and
members that are groups (called nested or sub groups). The
- <code>AuthLDAPSubGroupAttribute</code> directive identifies the
+ <code class="directive"><a href="#authldapsubgroupattribute">AuthLDAPSubGroupAttribute</a></code>
+ directive identifies the
labels of members that may be sub-groups of the current group
- (as opposed to user members). The <code>AuthLDAPSubGroupClass</code>
+ (as opposed to user members). The <code class="directive">AuthLDAPSubGroupClass</code>
directive specifies the LDAP objectClass values used in verifying that
these potential sub-groups are in fact group objects. Verified sub-groups
can then be searched for more user or sub-group members. Multiple
limited to approximately 8000 characters (the definition of
<code>MAX_STRING_LEN</code> in the Apache source code). This
should be more than sufficient for any application. In 2.4.10 and later,
- The word "none" may be used to not use any filter, which may be
+ the keyword <code>none</code> disables the use of a filter; this is
required by some primitive LDAP servers.</dd>
</dl>
upgraded to a secure connection on the same port.</dd>
</dl>
- <p>See above for examples of <code class="directive"><a href="#authldapurl">AuthLDAPURL</a></code> URLs.</p>
+ <p>See above for examples of <code class="directive"><a href="#authldapurl">AuthLDAPUrl</a></code> URLs.</p>
</div>
</div>
projects / apache / commitdiff