| <?xml version="1.0"?> |
| <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <modulesynopsis metafile="mod_authnz_ldap.xml.meta"> |
| |
| <name>mod_authnz_ldap</name> |
| <description>Allows an LDAP directory to be used to store the database |
| for HTTP Basic authentication.</description> |
| <status>Extension</status> |
| <sourcefile>mod_authnz_ldap.c</sourcefile> |
| <identifier>authnz_ldap_module</identifier> |
| <compatibility>Available in version 2.1 and later</compatibility> |
| |
| <summary> |
| <p>This module allows authentication front-ends such as |
| <module>mod_auth_basic</module> to authenticate users through |
| an ldap directory.</p> |
| |
| <p><module>mod_authnz_ldap</module> 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), <a href="http://developer.novell.com/ndk/cldap.htm"> |
| Novell LDAP SDK</a> 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>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 or Novell LDAP SDK).</li> |
| </ul> |
| |
| <p>When using <module>mod_auth_basic</module>, this module is invoked |
| via the <directive module="mod_auth_basic">AuthBasicProvider</directive> |
| directive with the <code>ldap</code> value.</p> |
| </summary> |
| |
| <seealso><module>mod_ldap</module></seealso> |
| <seealso><module>mod_auth_basic</module></seealso> |
| <seealso><module>mod_authz_user</module></seealso> |
| <seealso><module>mod_authz_groupfile</module></seealso> |
| |
| <section id="contents"><title>Contents</title> |
| |
| <ul> |
| <li> <a href="#gcaveats">General caveats</a> </li> |
| <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="#requser">Require ldap-user</a></li> |
| <li><a href="#reqgroup">Require ldap-group</a></li> |
| <li><a href="#reqdn">Require ldap-dn</a></li> |
| <li><a href="#reqattribute">Require ldap-attribute</a></li> |
| <li><a href="#reqfilter">Require ldap-filter</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="#exposed">Exposing Login Information</a></li> |
| <li><a href="#activedirectory">Using Active Directory</a></li> |
| <li> |
| <a href="#frontpage">Using Microsoft FrontPage with |
| <module>mod_authnz_ldap</module></a> |
| |
| <ul> |
| <li><a href="#howitworks">How It Works</a></li> |
| <li><a href="#fpcaveats">Caveats</a></li> |
| </ul> |
| </li> |
| </ul> |
| </section> |
| |
| <section id="gcaveats"><title>General caveats</title> |
| <p> This module caches authentication and authorization results based |
| on the configuration of <module>mod_ldap</module>. Changes |
| made to the backing LDAP server will not be immediately reflected on the |
| HTTP Server, including but not limited to user lockouts/revocations, |
| password changes, or changes to group memberships. Consult the directives |
| in <module>mod_ldap</module> for details of the cache tunables. |
| </p> |
| </section> |
| |
| <section id="operation"><title>Operation</title> |
| |
| <p>There are two phases in granting access to a user. The first |
| phase is authentication, in which the <module>mod_authnz_ldap</module> |
| authentication provider verifies that the user's credentials are valid. |
| This is also called the <em>search/bind</em> phase. The second phase is |
| authorization, in which <module>mod_authnz_ldap</module> determines |
| if the authenticated user is allowed access to the resource in |
| question. This is also known as the <em>compare</em> |
| phase.</p> |
| |
| <p><module>mod_authnz_ldap</module> registers both an authn_ldap authentication |
| provider and an authz_ldap authorization handler. The authn_ldap |
| authentication provider can be enabled through the |
| <directive module="mod_auth_basic">AuthBasicProvider</directive> directive |
| using the <code>ldap</code> value. The authz_ldap handler extends the |
| <directive module="mod_authz_core">Require</directive> directive's authorization types |
| by adding <code>ldap-user</code>, <code>ldap-dn</code> and <code>ldap-group</code> |
| values.</p> |
| |
| <section id="authenphase"><title>The Authentication |
| Phase</title> |
| |
| <p>During the authentication phase, <module>mod_authnz_ldap</module> |
| searches for an entry in the directory that matches the username |
| that the HTTP client passes. If a single unique match is found, |
| then <module>mod_authnz_ldap</module> 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 <directive module="mod_authnz_ldap" |
| >AuthLDAPURL</directive> 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 that |
| 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> |
| <columnspec><column width=".3"/><column width=".7"/></columnspec> |
| <tr> |
| <td><directive module="mod_authnz_ldap">AuthLDAPURL</directive></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><directive module="mod_authnz_ldap">AuthLDAPBindDN</directive></td> |
| |
| <td>An optional DN to bind with |
| during the search phase.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPBindPassword</directive></td> |
| |
| <td>An optional password to bind |
| with during the search phase.</td> |
| </tr> |
| </table> |
| </section> |
| |
| <section id="authorphase"><title>The Authorization Phase</title> |
| |
| <p>During the authorization phase, <module>mod_authnz_ldap</module> |
| attempts to determine if the user is authorized to access the |
| resource. Many of these checks require |
| <module>mod_authnz_ldap</module> to do a compare operation on the |
| LDAP server. This is why this phase is often referred to as the |
| compare phase. <module>mod_authnz_ldap</module> accepts the |
| following <directive module="mod_authz_core">Require</directive> |
| directives to determine if the credentials are acceptable:</p> |
| |
| <ul> |
| <li>Grant access if there is a <a |
| href="#reqgroup"><code>Require ldap-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 |
| ldap-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 ldap-group</code></a> directive, and |
| the DN fetched from the LDAP directory (or the username |
| passed by the client) occurs in the LDAP group or, potentially, in |
| one of its sub-groups.</li> |
| |
| <li>Grant access if there is a <a href="#reqattribute"> |
| <code>Require ldap-attribute</code></a> |
| directive, and the attribute fetched from the LDAP directory |
| matches the given value.</li> |
| |
| <li>Grant access if there is a <a href="#reqfilter"> |
| <code>Require ldap-filter</code></a> |
| directive, and the search filter successfully finds a single user |
| object that matches the dn of the authenticated user.</li> |
| |
| <li>otherwise, deny or decline access</li> |
| </ul> |
| |
| <p>Other <directive module="mod_authz_core">Require</directive> values may also |
| be used which may require loading additional authorization modules.</p> |
| |
| <ul> |
| <li>Grant access to all successfully authenticated users if |
| there is a <a href="#requser"><code>Require valid-user</code></a> |
| directive. (requires <module>mod_authz_user</module>)</li> |
| |
| <li>Grant access if there is a <a |
| href="#reqgroup"><code>Require group</code></a> directive, and |
| <module>mod_authz_groupfile</module> has been loaded with the |
| <directive module="mod_authz_groupfile">AuthGroupFile</directive> |
| directive set.</li> |
| |
| <li>others...</li> |
| </ul> |
| |
| |
| <p><module>mod_authnz_ldap</module> uses the following directives during the |
| compare phase:</p> |
| |
| <table> |
| <columnspec><column width=".4"/><column width=".6"/></columnspec> |
| <tr> |
| <td><directive module="mod_authnz_ldap">AuthLDAPURL</directive> </td> |
| |
| <td>The attribute specified in the |
| URL is used in compare operations for the <code>Require |
| ldap-user</code> operation.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPCompareDNOnServer</directive></td> |
| |
| <td>Determines the behavior of the |
| <code>Require ldap-dn</code> directive.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive></td> |
| |
| <td>Determines the attribute to |
| use for comparisons in the <code>Require ldap-group</code> |
| directive.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPGroupAttributeIsDN</directive></td> |
| |
| <td>Specifies whether to use the |
| user DN or the username when doing comparisons for the |
| <code>Require ldap-group</code> directive.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive></td> |
| |
| <td>Determines the maximum depth of sub-groups that will be evaluated |
| during comparisons in the <code>Require ldap-group</code> directive.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive></td> |
| |
| <td>Determines the attribute to use when obtaining sub-group members |
| of the current group during comparisons in the <code>Require ldap-group</code> |
| directive.</td> |
| </tr> |
| |
| <tr> |
| <td><directive |
| module="mod_authnz_ldap">AuthLDAPSubGroupClass</directive></td> |
| |
| <td>Specifies the LDAP objectClass values used to identify if queried directory |
| objects really are group objects (as opposed to user objects) during the |
| <code>Require ldap-group</code> directive's sub-group processing.</td> |
| </tr> |
| </table> |
| </section> |
| </section> |
| |
| <section id="requiredirectives"><title>The Require Directives</title> |
| |
| <p>Apache's <directive module="mod_authz_core">Require</directive> |
| directives are used during the authorization phase to ensure that |
| a user is allowed to access a resource. mod_authnz_ldap extends the |
| authorization types with <code>ldap-user</code>, <code>ldap-dn</code>, |
| <code>ldap-group</code>, <code>ldap-attribute</code> and |
| <code>ldap-filter</code>. Other authorization types may also be |
| used but may require that additional authorization modules be loaded.</p> |
| |
| <p>Since v2.4.8, <a href="../expr.html">expressions</a> are supported |
| within the LDAP require directives.</p> |
| |
| <section id="requser"><title>Require ldap-user</title> |
| |
| <p>The <code>Require ldap-user</code> directive specifies what |
| usernames can access the resource. Once |
| <module>mod_authnz_ldap</module> has retrieved a unique DN from the |
| directory, it does an LDAP compare operation using the username |
| specified in the <code>Require ldap-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 surrounded with double quotes. Multiple users can also be |
| granted access by using multiple <code>Require ldap-user</code> |
| directives, with one user per line. For example, with a <directive |
| module="mod_authnz_ldap">AuthLDAPURL</directive> of |
| <code>ldap://ldap/o=Example?cn</code> (i.e., <code>cn</code> is |
| used for searches), the following Require directives could be used |
| to restrict access:</p> |
| <highlight language="config"> |
| Require ldap-user "Barbara Jenson" |
| Require ldap-user "Fred User" |
| Require ldap-user "Joe Manager" |
| </highlight> |
| |
| <p>Because of the way that <module>mod_authnz_ldap</module> 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 |
| ldap-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> |
| <highlight language="config"> |
| Require ldap-user bjenson fuser jmanager |
| </highlight> |
| </section> |
| |
| <section id="reqgroup"><title>Require ldap-group</title> |
| |
| <p>This directive specifies an LDAP group whose members are |
| allowed access. It takes the distinguished name of the LDAP |
| group. Note: Do not surround the group name with quotes. |
| For example, assume that the following entry existed in |
| the LDAP directory:</p> |
| <example><pre> |
| dn: cn=Administrators, o=Example |
| objectClass: groupOfUniqueNames |
| uniqueMember: cn=Barbara Jenson, o=Example |
| uniqueMember: cn=Fred User, o=Example |
| </pre></example> |
| |
| <p>The following directive would grant access to both Fred and |
| Barbara:</p> |
| <highlight language="config"> |
| Require ldap-group cn=Administrators, o=Example |
| </highlight> |
| |
| <p>Members can also be found within sub-groups of a specified LDAP group |
| if <directive module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive> |
| is set to a value greater than 0. For example, assume the following entries |
| exist in the LDAP directory:</p> |
| <example><pre> |
| dn: cn=Employees, o=Example |
| objectClass: groupOfUniqueNames |
| uniqueMember: cn=Managers, o=Example |
| uniqueMember: cn=Administrators, o=Example |
| uniqueMember: cn=Users, o=Example |
| |
| dn: cn=Managers, o=Example |
| objectClass: groupOfUniqueNames |
| uniqueMember: cn=Bob Ellis, o=Example |
| uniqueMember: cn=Tom Jackson, o=Example |
| |
| dn: cn=Administrators, o=Example |
| objectClass: groupOfUniqueNames |
| uniqueMember: cn=Barbara Jenson, o=Example |
| uniqueMember: cn=Fred User, o=Example |
| |
| dn: cn=Users, o=Example |
| objectClass: groupOfUniqueNames |
| uniqueMember: cn=Allan Jefferson, o=Example |
| uniqueMember: cn=Paul Tilley, o=Example |
| uniqueMember: cn=Temporary Employees, o=Example |
| |
| dn: cn=Temporary Employees, o=Example |
| objectClass: groupOfUniqueNames |
| uniqueMember: cn=Jim Swenson, o=Example |
| uniqueMember: cn=Elliot Rhodes, o=Example |
| </pre></example> |
| |
| <p>The following directives would allow access for Bob Ellis, Tom Jackson, |
| Barbara Jenson, Fred User, Allan Jefferson, and Paul Tilley but would not |
| allow access for Jim Swenson, or Elliot Rhodes (since they are at a |
| sub-group depth of 2):</p> |
| <highlight language="config"> |
| Require ldap-group cn=Employees, o=Example |
| AuthLDAPMaxSubGroupDepth 1 |
| </highlight> |
| |
| <p>Behavior of this directive is modified by the <directive |
| module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive>, <directive |
| module="mod_authnz_ldap">AuthLDAPGroupAttributeIsDN</directive>, <directive |
| module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive>, <directive |
| module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive>, and <directive |
| module="mod_authnz_ldap">AuthLDAPSubGroupClass</directive> |
| directives.</p> |
| </section> |
| |
| <section id="reqdn"><title>Require ldap-dn</title> |
| |
| <p>The <code>Require ldap-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 ldap-dn</code>, then |
| authorization is granted. Note: do not surround the distinguished |
| name with quotes.</p> |
| |
| <p>The following directive would grant access to a specific |
| DN:</p> |
| <highlight language="config"> |
| Require ldap-dn cn=Barbara Jenson, o=Example |
| </highlight> |
| |
| <p>Behavior of this directive is modified by the <directive |
| module="mod_authnz_ldap">AuthLDAPCompareDNOnServer</directive> |
| directive.</p> |
| </section> |
| |
| <section id="reqattribute"><title>Require ldap-attribute</title> |
| |
| <p>The <code>Require ldap-attribute</code> directive allows the |
| administrator to grant access based on attributes of the authenticated |
| user in the LDAP directory. If the attribute in the directory |
| matches the value given in the configuration, access is granted.</p> |
| |
| <p>The following directive would grant access to anyone with |
| the attribute employeeType = active</p> |
| |
| <highlight language="config"> |
| Require ldap-attribute "employeeType=active" |
| </highlight> |
| |
| <p>Multiple attribute/value pairs can be specified on the same line |
| separated by spaces or they can be specified in multiple |
| <code>Require ldap-attribute</code> directives. The effect of listing |
| multiple attribute/values pairs is an OR operation. Access will be |
| granted if any of the listed attribute values match the value of the |
| corresponding attribute in the user object. If the value of the |
| attribute contains a space, only the value must be within double quotes.</p> |
| |
| <p>The following directive would grant access to anyone with |
| the city attribute equal to "San Jose" or status equal to "Active"</p> |
| |
| <highlight language="config"> |
| Require ldap-attribute city="San Jose" "status=active" |
| </highlight> |
| |
| </section> |
| |
| <section id="reqfilter"><title>Require ldap-filter</title> |
| |
| <p>The <code>Require ldap-filter</code> directive allows the |
| administrator to grant access based on a complex LDAP search filter. |
| If the dn returned by the filter search matches the authenticated user |
| dn, access is granted.</p> |
| |
| <p>The following directive would grant access to anyone having a cell phone |
| and is in the marketing department</p> |
| |
| <highlight language="config"> |
| Require ldap-filter "&(cell=*)(department=marketing)" |
| </highlight> |
| |
| <p>The difference between the <code>Require ldap-filter</code> directive and the |
| <code>Require ldap-attribute</code> directive is that <code>ldap-filter</code> |
| performs a search operation on the LDAP directory using the specified search |
| filter rather than a simple attribute comparison. If a simple attribute |
| comparison is all that is required, the comparison operation performed by |
| <code>ldap-attribute</code> will be faster than the search operation |
| used by <code>ldap-filter</code> especially within a large directory.</p> |
| |
| </section> |
| |
| </section> |
| |
| <section id="examples"><title>Examples</title> |
| |
| <ul> |
| <li> |
| Grant access to anyone who exists in the LDAP directory, |
| using their UID for searches. |
| <highlight language="config"> |
| AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)" |
| Require valid-user |
| </highlight> |
| </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. |
| <highlight language="config"> |
| AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example" |
| Require valid-user |
| </highlight> |
| </li> |
| |
| <li> |
| The next example is similar to the previous one, but it |
| 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>. |
| <highlight language="config"> |
| AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn" |
| Require valid-user |
| </highlight> |
| </li> |
| |
| <li> |
| Grant access to anybody in the Administrators group. The |
| users must authenticate using their UID. |
| <highlight language="config"> |
| AuthLDAPURL ldap://ldap.example.com/o=Example?uid |
| Require ldap-group cn=Administrators, o=Example |
| </highlight> |
| </li> |
| |
| <li> |
| Grant access to anybody in the group whose name matches the |
| hostname of the virtual host. In this example an |
| <a href="../expr.html">expression</a> is used to build the filter. |
| <highlight language="config"> |
| AuthLDAPURL ldap://ldap.example.com/o=Example?uid |
| Require ldap-group cn=%{SERVER_NAME}, o=Example |
| </highlight> |
| </li> |
| |
| <li> |
| The next example assumes that everyone at Example 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: |
| <highlight language="config"> |
| AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*) |
| Require valid-user |
| </highlight> |
| </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 pager, plus grant access to Joe Manager, who doesn't |
| have a pager, but does need to access the same |
| resource:</p> |
| <highlight language="config"> |
| AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager)) |
| Require valid-user |
| </highlight> |
| |
| <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. If |
| Fred User connects as <code>fuser</code>, the filter would look |
| like</p> |
| |
| <example>(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))</example> |
| |
| <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> |
| |
| <example>(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))</example> |
| |
| <p>The above search will succeed whether <em>jmanager</em> |
| has a pager or not.</p> |
| </li> |
| </ul> |
| </section> |
| |
| <section id="usingtls"><title>Using TLS</title> |
| |
| <p>To use TLS, see the <module>mod_ldap</module> directives <directive |
| module="mod_ldap">LDAPTrustedClientCert</directive>, <directive |
| module="mod_ldap">LDAPTrustedGlobalCert</directive> and <directive |
| module="mod_ldap">LDAPTrustedMode</directive>.</p> |
| |
| <p>An optional second parameter can be added to the |
| <directive module="mod_authnz_ldap">AuthLDAPURL</directive> to override |
| the default connection type set by <directive module="mod_ldap">LDAPTrustedMode</directive>. |
| This will allow the connection established by an <em>ldap://</em> Url |
| to be upgraded to a secure connection on the same port.</p> |
| </section> |
| |
| <section id="usingssl"><title>Using SSL</title> |
| |
| <p>To use SSL, see the <module>mod_ldap</module> directives <directive |
| module="mod_ldap">LDAPTrustedClientCert</directive>, <directive |
| module="mod_ldap">LDAPTrustedGlobalCert</directive> and <directive |
| module="mod_ldap">LDAPTrustedMode</directive>.</p> |
| |
| <p>To specify a secure LDAP server, use <em>ldaps://</em> in the |
| <directive module="mod_authnz_ldap">AuthLDAPURL</directive> |
| directive, instead of <em>ldap://</em>.</p> |
| </section> |
| |
| <section id="exposed"><title>Exposing Login Information</title> |
| |
| <p>when this module performs <em>authentication</em>, ldap attributes specified |
| in the <directive module="mod_authnz_ldap">authldapurl</directive> |
| directive are placed in environment variables with the prefix "AUTHENTICATE_".</p> |
| |
| <p>when this module performs <em>authorization</em>, ldap attributes specified |
| in the <directive module="mod_authnz_ldap">authldapurl</directive> |
| directive are placed in environment variables with the prefix "AUTHORIZE_".</p> |
| |
| <p>If the attribute field contains the username, common name |
| and telephone number of a user, a CGI program will have access to |
| this information without the need to make a second independent LDAP |
| query to gather this additional information.</p> |
| |
| <p>This has the potential to dramatically simplify the coding and |
| configuration required in some web applications.</p> |
| |
| </section> |
| |
| <section id="activedirectory"><title>Using Active Directory</title> |
| |
| <p>An Active Directory installation may support multiple domains at the |
| same time. To distinguish users between domains, an identifier called |
| a User Principle Name (UPN) can be added to a user's entry in the |
| directory. This UPN usually takes the form of the user's account |
| name, followed by the domain components of the particular domain, |
| for example <em>somebody@nz.example.com</em>.</p> |
| |
| <p>You may wish to configure the <module>mod_authnz_ldap</module> |
| module to authenticate users present in any of the domains making up |
| the Active Directory forest. In this way both |
| <em>somebody@nz.example.com</em> and <em>someone@au.example.com</em> |
| can be authenticated using the same query at the same time.</p> |
| |
| <p>To make this practical, Active Directory supports the concept of |
| a Global Catalog. This Global Catalog is a read only copy of selected |
| attributes of all the Active Directory servers within the Active |
| Directory forest. Querying the Global Catalog allows all the domains |
| to be queried in a single query, without the query spanning servers |
| over potentially slow links.</p> |
| |
| <p>If enabled, the Global Catalog is an independent directory server |
| that runs on port 3268 (3269 for SSL). To search for a user, do a |
| subtree search for the attribute <em>userPrincipalName</em>, with |
| an empty search root, like so:</p> |
| |
| <highlight language="config"> |
| AuthLDAPBindDN apache@example.com |
| AuthLDAPBindPassword password |
| AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub |
| </highlight> |
| |
| <p>Users will need to enter their User Principal Name as a login, in |
| the form <em>somebody@nz.example.com</em>.</p> |
| |
| </section> |
| |
| <section id="frontpage"><title>Using Microsoft |
| FrontPage with mod_authnz_ldap</title> |
| |
| <p>Normally, FrontPage uses FrontPage-web-specific user/group |
| files (i.e., the <module>mod_authn_file</module> and |
| <module>mod_authz_groupfile</module> modules) 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> |
| <highlight language="config"> |
| AuthLDAPURL "the url" |
| AuthGroupFile "mygroupfile" |
| Require group "mygroupfile" |
| </highlight> |
| |
| <section id="howitworks"><title>How It Works</title> |
| |
| <p>FrontPage restricts access to a web by adding the <code>Require |
| valid-user</code> directive to the <code>.htaccess</code> |
| files. 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. By substituting the ldap-group with group file authorization, |
| Apache is allowed to consult the local user file (which is managed by |
| FrontPage) - instead of LDAP - when handling authorizing the user.</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> |
| </section> |
| |
| <section id="fpcaveats"><title>Caveats</title> |
| |
| <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 <module>mod_authn_file</module> 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> |
| |
| <!-- XXX is that true? was mod_auth before the aaa change --> |
| <li>Apache must be compiled with <module>mod_auth_basic</module>, |
| <module>mod_authn_file</module> and |
| <module>mod_authz_groupfile</module> in order to |
| use FrontPage support. This is because Apache will still use |
| the <module>mod_authz_groupfile</module> 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 <directive module="core" |
| type="section">Location</directive> or <directive module="core" |
| type="section">Directory</directive> directives won't work. This |
| is because <module>mod_authnz_ldap</module> has to be able to grab |
| the <directive module="mod_authz_groupfile">AuthGroupFile</directive> |
| directive that is found in FrontPage <code>.htaccess</code> |
| files so that it knows where to look for the valid user list. If |
| the <module>mod_authnz_ldap</module> directives aren't in the same |
| <code>.htaccess</code> file as the FrontPage directives, then |
| the hack won't work, because <module>mod_authnz_ldap</module> 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> |
| </section> |
| </section> |
| |
| <directivesynopsis> |
| <name>AuthLDAPAuthorizePrefix</name> |
| <description>Specifies the prefix for environment variables set during |
| authorization</description> |
| <syntax>AuthLDAPAuthorizePrefix <em>prefix</em></syntax> |
| <default>AuthLDAPAuthorizePrefix AUTHORIZE_</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.6 and later</compatibility> |
| <usage> |
| <p>This directive allows you to override the prefix used for environment |
| variables set during LDAP authorization. If <em>AUTHENTICATE_</em> is |
| specified, consumers of these environment variables see the same information |
| whether LDAP has performed authentication, authorization, or both.</p> |
| |
| <note><title>Note</title> |
| No authorization variables are set when a user is authorized on the basis of |
| <code>Require valid-user</code>. |
| </note> |
| </usage> |
| </directivesynopsis> |
| |
| |
| <directivesynopsis> |
| <name>AuthLDAPBindAuthoritative</name> |
| <description>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.</description> |
| <syntax>AuthLDAPBindAuthoritative off|on</syntax> |
| <default>AuthLDAPBindAuthoritative on</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <usage> |
| <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 <directive>AuthLDAPBindAuthoritative</directive> |
| 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> |
| <p> This allows users present in both LDAP and |
| <directive module="mod_authn_file">AuthUserFile</directive> to authenticate |
| when the LDAP server is available but the user's account is locked or password |
| is otherwise unusable.</p> |
| </usage> |
| <seealso><directive module="mod_authn_file">AuthUserFile</directive></seealso> |
| <seealso><directive module="mod_auth_basic">AuthBasicProvider</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPInitialBindAsUser</name> |
| <description>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</description> |
| <syntax>AuthLDAPInitialBindAsUser off|on</syntax> |
| <default>AuthLDAPInitialBindAsUser off</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.6 and later</compatibility> |
| <usage> |
| <p>By default, the server either anonymously, or with a dedicated user and |
| password, converts the basic authentication username into an LDAP |
| distinguished name (DN). This directive forces the server to use the verbatim username |
| and password provided by the incoming user to perform the initial DN |
| search.</p> |
| |
| <p> If the verbatim username can't directly bind, but needs some |
| cosmetic transformation, see <directive module="mod_authnz_ldap"> |
| AuthLDAPInitialBindPattern</directive>.</p> |
| |
| <p> This directive should only be used when your LDAP server doesn't |
| accept anonymous searches and you cannot use a dedicated |
| <directive module="mod_authnz_ldap">AuthLDAPBindDN</directive>. |
| </p> |
| |
| <note><title>Not available with authorization-only</title> |
| This directive can only be used if this module authenticates the user, and |
| has no effect when this module is used exclusively for authorization. |
| </note> |
| </usage> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindPattern</directive></seealso> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPBindDN</directive></seealso> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive></seealso> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPInitialBindPattern</name> |
| <description>Specifies the transformation of the basic authentication username to be used when binding to the LDAP server |
| to perform a DN lookup</description> |
| <syntax>AuthLDAPInitialBindPattern <em><var>regex</var> <var>substitution</var></em></syntax> |
| <default>AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.6 and later</compatibility> |
| <usage> |
| <p>If <directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive> is set to |
| <em>ON</em>, the basic authentication username will be transformed according to the |
| regular expression and substitution arguments.</p> |
| |
| <p> The regular expression argument is compared against the current basic authentication username. |
| The substitution argument may contain backreferences, but has no other variable interpolation.</p> |
| |
| <p> This directive should only be used when your LDAP server doesn't |
| accept anonymous searches and you cannot use a dedicated |
| <directive module="mod_authnz_ldap">AuthLDAPBindDN</directive>. |
| </p> |
| |
| <highlight language="config"> |
| AuthLDAPInitialBindPattern (.+) $1@example.com |
| </highlight> |
| <highlight language="config"> |
| AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com |
| </highlight> |
| |
| <note><title>Not available with authorization-only</title> |
| This directive can only be used if this module authenticates the user, and |
| has no effect when this module is used exclusively for authorization. |
| </note> |
| <note><title>debugging</title> |
| The substituted DN is recorded in the environment variable |
| <em>LDAP_BINDASUSER</em>. If the regular expression does not match the input, |
| the verbatim username is used. |
| </note> |
| </usage> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPBindDN</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPBindDN</name> |
| <description>Optional DN to use in binding to the LDAP server</description> |
| <syntax>AuthLDAPBindDN <em>distinguished-name</em></syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>An optional DN used to bind to the server when searching for |
| entries. If not provided, <module>mod_authnz_ldap</module> will use |
| an anonymous bind.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPBindPassword</name> |
| <description>Password used in conjuction with the bind DN</description> |
| <syntax>AuthLDAPBindPassword <em>password</em></syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility><em>exec:</em> was added in 2.4.5.</compatibility> |
| |
| <usage> |
| <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 <directive |
| module="mod_authnz_ldap">AuthLDAPBindDN</directive> and <directive |
| >AuthLDAPBindPassword</directive> if you |
| absolutely need them to search the directory.</p> |
| |
| <p>If the value begins with exec: the resulting command will be |
| executed and the first line returned to standard output by the |
| program will be used as the password.</p> |
| <highlight language="config"> |
| #Password used as-is |
| AuthLDAPBindPassword secret |
| |
| #Run /path/to/program to get my password |
| AuthLDAPBindPassword exec:/path/to/program |
| |
| #Run /path/to/otherProgram and provide arguments |
| AuthLDAPBindPassword "exec:/path/to/otherProgram argument1" |
| </highlight> |
| |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPCharsetConfig</name> |
| <description>Language to charset conversion configuration file</description> |
| <syntax>AuthLDAPCharsetConfig <em>file-path</em></syntax> |
| <contextlist><context>server config</context> |
| </contextlist> |
| |
| <usage> |
| <p>The <directive>AuthLDAPCharsetConfig</directive> directive sets the location |
| of the language to charset conversion configuration file. <var>File-path</var> is relative |
| to the <directive module="core">ServerRoot</directive>. This file specifies |
| the list of language extensions to character sets. |
| Most administrators use the provided <code>charset.conv</code> |
| file, which associates common language extensions to character sets.</p> |
| |
| <p>The file contains lines in the following format:</p> |
| |
| <example> |
| <var>Language-Extension</var> <var>charset</var> [<var>Language-String</var>] ... |
| </example> |
| |
| <p>The case of the extension does not matter. Blank lines, and lines |
| beginning with a hash character (<code>#</code>) are ignored.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPCompareAsUser</name> |
| <description>Use the authenticated user's credentials to perform authorization comparisons</description> |
| <syntax>AuthLDAPCompareAsUser on|off</syntax> |
| <default>AuthLDAPCompareAsUser off</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.6 and later</compatibility> |
| |
| <usage> |
| <p>When set, and <module>mod_authnz_ldap</module> has authenticated the |
| user, LDAP comparisons for authorization use the queried distinguished name (DN) |
| and HTTP basic authentication password of the authenticated user instead of |
| the servers configured credentials.</p> |
| |
| <p> The <em>ldap-attribute</em>, <em>ldap-user</em>, and <em>ldap-group</em> (single-level only) |
| authorization checks use comparisons.</p> |
| |
| <p>This directive only has effect on the comparisons performed during |
| nested group processing when <directive module="mod_authnz_ldap"> |
| AuthLDAPSearchAsUser</directive> is also enabled.</p> |
| |
| <p> This directive should only be used when your LDAP server doesn't |
| accept anonymous comparisons and you cannot use a dedicated |
| <directive module="mod_authnz_ldap">AuthLDAPBindDN</directive>. |
| </p> |
| </usage> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPCompareDNOnServer</name> |
| <description>Use the LDAP server to compare the DNs</description> |
| <syntax>AuthLDAPCompareDNOnServer on|off</syntax> |
| <default>AuthLDAPCompareDNOnServer on</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>When set, <module>mod_authnz_ldap</module> will use the LDAP |
| server to compare the DNs. This is the only foolproof way to |
| compare DNs. <module>mod_authnz_ldap</module> 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, |
| <module>mod_authnz_ldap</module> simply does a string comparison. It |
| is possible to get false negatives with this approach, but it is |
| much faster. Note the <module>mod_ldap</module> cache can speed up |
| DN comparison in most situations.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPDereferenceAliases</name> |
| <description>When will the module de-reference aliases</description> |
| <syntax>AuthLDAPDereferenceAliases never|searching|finding|always</syntax> |
| <default>AuthLDAPDereferenceAliases always</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>This directive specifies when <module>mod_authnz_ldap</module> will |
| de-reference aliases during LDAP operations. The default is |
| <code>always</code>.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPGroupAttribute</name> |
| <description>LDAP attributes used to identify the user members of |
| groups.</description> |
| <syntax>AuthLDAPGroupAttribute <em>attribute</em></syntax> |
| <default>AuthLDAPGroupAttribute member uniquemember</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>This directive specifies which LDAP attributes are used to |
| check for user members within groups. Multiple attributes can be used |
| by specifying this directive multiple times. If not specified, |
| then <module>mod_authnz_ldap</module> uses the <code>member</code> and |
| <code>uniquemember</code> attributes.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPGroupAttributeIsDN</name> |
| <description>Use the DN of the client username when checking for |
| group membership</description> |
| <syntax>AuthLDAPGroupAttributeIsDN on|off</syntax> |
| <default>AuthLDAPGroupAttributeIsDN on</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <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=Example</code>. If this directive is set, |
| <module>mod_authnz_ldap</module> will check if the group has |
| <code>cn=Babs Jenson, o=Example</code> as a member. If this |
| directive is not set, then <module>mod_authnz_ldap</module> will |
| check if the group has <code>bjenson</code> as a member.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPMaxSubGroupDepth</name> |
| <description>Specifies the maximum sub-group nesting depth that will be |
| evaluated before the user search is discontinued.</description> |
| <syntax>AuthLDAPMaxSubGroupDepth <var>Number</var></syntax> |
| <default>AuthLDAPMaxSubGroupDepth 10</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.0 and later</compatibility> |
| |
| <usage> |
| <p>When this directive is set to a non-zero value <code>X</code> |
| combined with use of the <code>Require ldap-group someGroupDN</code> |
| directive, the provided user credentials will be searched for |
| as a member of the <code>someGroupDN</code> directory object or of |
| any group member of the current group up to the maximum nesting |
| level <code>X</code> specified by this directive.</p> |
| <p>See the <a href="#reqgroup"><code>Require ldap-group</code></a> |
| section for a more detailed example.</p> |
| |
| <note><title>Nested groups performance</title> |
| <p> When <directive>AuthLDAPSubGroupAttribute</directive> overlaps with |
| <directive>AuthLDAPGroupAttribute</directive> (as it does by default and |
| as required by common LDAP schemas), uncached searching for subgroups in |
| large groups can be very slow. If you use large, non-nested groups, set |
| <directive>AuthLDAPMaxSubGroupDepth</directive> to zero.</p> |
| </note> |
| |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPRemoteUserAttribute</name> |
| <description>Use the value of the attribute returned during the user |
| query to set the REMOTE_USER environment variable</description> |
| <syntax>AuthLDAPRemoteUserAttribute uid</syntax> |
| <default>none</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>If this directive is set, the value of the |
| <code>REMOTE_USER</code> environment variable will be set to the |
| 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 <directive module="mod_authnz_ldap" |
| >AuthLDAPRemoteUserIsDN</directive>. 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> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPRemoteUserIsDN</name> |
| <description>Use the DN of the client username to set the REMOTE_USER |
| environment variable</description> |
| <syntax>AuthLDAPRemoteUserIsDN on|off</syntax> |
| <default>AuthLDAPRemoteUserIsDN off</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <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> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPSearchAsUser</name> |
| <description>Use the authenticated user's credentials to perform authorization searches</description> |
| <syntax>AuthLDAPSearchAsUser on|off</syntax> |
| <default>AuthLDAPSearchAsUser off</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.6 and later</compatibility> |
| |
| <usage> |
| <p>When set, and <module>mod_authnz_ldap</module> has authenticated the |
| user, LDAP searches for authorization use the queried distinguished name (DN) |
| and HTTP basic authentication password of the authenticated user instead of |
| the servers configured credentials.</p> |
| |
| <p> The <em>ldap-filter</em> and <em>ldap-dn</em> authorization |
| checks use searches.</p> |
| |
| <p>This directive only has effect on the comparisons performed during |
| nested group processing when <directive module="mod_authnz_ldap"> |
| AuthLDAPCompareAsUser</directive> is also enabled.</p> |
| |
| <p> This directive should only be used when your LDAP server doesn't |
| accept anonymous searches and you cannot use a dedicated |
| <directive module="mod_authnz_ldap">AuthLDAPBindDN</directive>. |
| </p> |
| </usage> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso> |
| <seealso><directive module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPSubGroupAttribute</name> |
| <description>Specifies the attribute labels, one value per |
| directive line, used to distinguish the members of the current group that |
| are groups.</description> |
| <syntax>AuthLDAPSubGroupAttribute <em>attribute</em></syntax> |
| <default>AuthLDAPSubgroupAttribute member uniquemember</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.0 and later</compatibility> |
| |
| <usage> |
| <p>An LDAP group object may contain members that are users and |
| members that are groups (called nested or sub groups). The |
| <directive>AuthLDAPSubGroupAttribute</directive> directive identifies the |
| labels of group members and the <directive module="mod_authnz_ldap" |
| >AuthLDAPGroupAttribute</directive> |
| directive identifies the labels of the user members. Multiple |
| attributes can be used by specifying this directive multiple times. |
| If not specified, then <module>mod_authnz_ldap</module> uses the |
| <code>member</code> and <code>uniqueMember</code> attributes.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPSubGroupClass</name> |
| <description>Specifies which LDAP objectClass values identify directory |
| objects that are groups during sub-group processing.</description> |
| <syntax>AuthLDAPSubGroupClass <em>LdapObjectClass</em></syntax> |
| <default>AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Available in version 2.3.0 and later</compatibility> |
| |
| <usage> |
| <p>An LDAP group object may contain members that are users and |
| members that are groups (called nested or sub groups). The |
| <directive module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive> |
| directive identifies the |
| labels of members that may be sub-groups of the current group |
| (as opposed to user members). The <directive>AuthLDAPSubGroupClass</directive> |
| 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 |
| attributes can be used by specifying this directive multiple times. |
| If not specified, then <module>mod_authnz_ldap</module> uses the |
| <code>groupOfNames</code> and <code>groupOfUniqueNames</code> values.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthLDAPUrl</name> |
| <description>URL specifying the LDAP search parameters</description> |
| <syntax>AuthLDAPUrl <em>url [NONE|SSL|TLS|STARTTLS]</em></syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>An RFC 2255 URL which specifies the LDAP search parameters |
| to use. The syntax of the URL is</p> |
| <example>ldap://host:port/basedn?attribute?scope?filter</example> |
| <p>If you want to specify more than one LDAP URL that Apache should try in turn, the syntax is:</p> |
| <highlight language="config"> |
| AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..." |
| </highlight> |
| <p><em><strong>Caveat: </strong>If you specify multiple servers, you need to enclose the entire URL string in quotes; |
| otherwise you will get an error: "AuthLDAPURL takes one argument, URL to define LDAP connection.." </em> |
| You can of course use search parameters on each of these.</p> |
| |
| <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. <module>mod_authnz_ldap</module> |
| will try connecting to each server in turn, until it makes a |
| successful connection. If multiple ldap servers are specified, |
| then entire LDAP URL must be encapsulated in double quotes.</p> |
| |
| <p>Once a connection has been made to a server, that |
| connection remains active for the life of the |
| <program>httpd</program> process, or until the LDAP server goes |
| down.</p> |
| |
| <p>If the LDAP server goes down and breaks an existing |
| connection, <module>mod_authnz_ldap</module> 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. All attributes |
| listed will be put into the environment with an AUTHENTICATE_ prefix |
| for use by other modules.</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 more than sufficient for any application. In 2.4.10 and later, |
| the keyword <code>none</code> disables the use of a filter; this is |
| required by some primitive LDAP servers.</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.example.com/o=Example?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>An optional parameter can be added to allow the LDAP Url to override |
| the connection type. This parameter can be one of the following:</p> |
| |
| <dl> |
| <dt>NONE</dt> |
| <dd>Establish an unsecure connection on the default LDAP port. This |
| is the same as <code>ldap://</code> on port 389.</dd> |
| <dt>SSL</dt> |
| <dd>Establish a secure connection on the default secure LDAP port. |
| This is the same as <code>ldaps://</code></dd> |
| <dt>TLS | STARTTLS</dt> |
| <dd>Establish an upgraded secure connection on the default LDAP port. |
| This connection will be initiated on port 389 by default and then |
| upgraded to a secure connection on the same port.</dd> |
| </dl> |
| |
| <p>See above for examples of <directive |
| module="mod_authnz_ldap">AuthLDAPUrl</directive> URLs.</p> |
| </usage> |
| </directivesynopsis> |
| |
| </modulesynopsis> |