<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.auth.adapter.ldap">
    <title>LDAP Authentication</title>

    <sect2 id="zend.auth.adapter.ldap.introduction">
        <title>Introduction</title>

        <para>
            <classname>Zend_Auth_Adapter_Ldap</classname> supports web application authentication
            with <acronym>LDAP</acronym> services. Its features include username and domain name
            canonicalization, multi-domain authentication, and failover capabilities. It has been
            tested to work with
            <ulink
                url="http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/">Microsoft
                Active Directory</ulink> and <ulink url="http://www.openldap.org/">OpenLDAP</ulink>,
            but it should also work with other <acronym>LDAP</acronym> service providers.
        </para>

        <para>
            This documentation includes a guide on using
            <classname>Zend_Auth_Adapter_Ldap</classname>, an exploration of its
            <acronym>API</acronym>, an outline of the various available options, diagnostic
            information for troubleshooting authentication problems, and example options for both
            Active Directory and OpenLDAP servers.
        </para>
    </sect2>

    <sect2 id="zend.auth.adapter.ldap.usage">
        <title>Usage</title>

        <para>
            To incorporate <classname>Zend_Auth_Adapter_Ldap</classname> authentication into your
            application quickly, even if you're not using <classname>Zend_Controller</classname>,
            the meat of your code should look something like the following:
        </para>

        <programlisting language="php"><![CDATA[
$username = $this->_request->getParam('username');
$password = $this->_request->getParam('password');

$auth = Zend_Auth::getInstance();

$config = new Zend_Config_Ini('../application/config/config.ini',
                              'production');
$log_path = $config->ldap->log_path;
$options = $config->ldap->toArray();
unset($options['log_path']);

$adapter = new Zend_Auth_Adapter_Ldap($options, $username,
                                      $password);

$result = $auth->authenticate($adapter);

if ($log_path) {
    $messages = $result->getMessages();

    $logger = new Zend_Log();
    $logger->addWriter(new Zend_Log_Writer_Stream($log_path));
    $filter = new Zend_Log_Filter_Priority(Zend_Log::DEBUG);
    $logger->addFilter($filter);

    foreach ($messages as $i => $message) {
        if ($i-- > 1) { // $messages[2] and up are log messages
            $message = str_replace("\n", "\n  ", $message);
            $logger->log("Ldap: $i: $message", Zend_Log::DEBUG);
        }
    }
}
]]></programlisting>

        <para>
            Of course, the logging code is optional, but it is highly recommended that you use a
            logger. <classname>Zend_Auth_Adapter_Ldap</classname> will record just about every bit
            of information anyone could want in <varname>$messages</varname> (more below), which is
            a nice feature in itself for something that has a history of being notoriously difficult
            to debug.
        </para>

        <para>
            The <classname>Zend_Config_Ini</classname> code is used above to load the adapter
            options. It is also optional. A regular array would work equally well. The following is
            an example <filename>application/config/config.ini</filename> file that has options for
            two separate servers. With multiple sets of server options the adapter will try each, in
            order, until the credentials are successfully authenticated. The names of the servers
            (e.g., 'server1' and 'server2') are largely arbitrary. For details regarding the options
            array, see the <emphasis>Server Options</emphasis> section below. Note that
            <classname>Zend_Config_Ini</classname> requires that any values with "equals" characters
            (<emphasis>=</emphasis>) will need to be quoted (like the DNs shown below).
        </para>

        <programlisting language="ini"><![CDATA[
[production]

ldap.log_path = /tmp/ldap.log

; Typical options for OpenLDAP
ldap.server1.host = s0.foo.net
ldap.server1.accountDomainName = foo.net
ldap.server1.accountDomainNameShort = FOO
ldap.server1.accountCanonicalForm = 3
ldap.server1.username = "CN=user1,DC=foo,DC=net"
ldap.server1.password = pass1
ldap.server1.baseDn = "OU=Sales,DC=foo,DC=net"
ldap.server1.bindRequiresDn = true

; Typical options for Active Directory
ldap.server2.host = dc1.w.net
ldap.server2.useStartTls = true
ldap.server2.accountDomainName = w.net
ldap.server2.accountDomainNameShort = W
ldap.server2.accountCanonicalForm = 3
ldap.server2.baseDn = "CN=Users,DC=w,DC=net"
]]></programlisting>

        <para>
            The above configuration will instruct <classname>Zend_Auth_Adapter_Ldap</classname> to
            attempt to authenticate users with the OpenLDAP server <filename>s0.foo.net</filename>
            first. If the authentication fails for any reason, the AD server
            <filename>dc1.w.net</filename> will be tried.
        </para>

        <para>
            With servers in different domains, this configuration illustrates multi-domain
            authentication. You can also have multiple servers in the same domain to provide
            redundancy.
        </para>

        <para>
            Note that in this case, even though OpenLDAP has no need for the short NetBIOS style
            domain name used by Windows, we provide it here for name canonicalization purposes
            (described in the <emphasis>Username Canonicalization</emphasis> section below).
        </para>
    </sect2>

    <sect2 id="zend.auth.adapter.ldap.api">
        <title>The API</title>

        <para>
            The <classname>Zend_Auth_Adapter_Ldap</classname> constructor accepts three parameters.
        </para>

        <para>
            The <varname>$options</varname> parameter is required and must be an array containing
            one or more sets of options. Note that it is <emphasis>an array of arrays</emphasis> of
            <link linkend="zend.ldap"><classname>Zend_Ldap</classname></link> options. Even if you
            will be using only one <acronym>LDAP</acronym> server, the options must still be within
            another array.
        </para>

        <para>
            Below is <ulink url="http://php.net/print_r"><methodname>print_r()</methodname></ulink>
            output of an example options parameter containing two sets of server options for
            <acronym>LDAP</acronym> servers <filename>s0.foo.net</filename> and
            <filename>dc1.w.net</filename> (the same options as the above <acronym>INI</acronym>
            representation):
        </para>

        <programlisting language="output"><![CDATA[
Array
(
    [server2] => Array
        (
            [host] => dc1.w.net
            [useStartTls] => 1
            [accountDomainName] => w.net
            [accountDomainNameShort] => W
            [accountCanonicalForm] => 3
            [baseDn] => CN=Users,DC=w,DC=net
        )

    [server1] => Array
        (
            [host] => s0.foo.net
            [accountDomainName] => foo.net
            [accountDomainNameShort] => FOO
            [accountCanonicalForm] => 3
            [username] => CN=user1,DC=foo,DC=net
            [password] => pass1
            [baseDn] => OU=Sales,DC=foo,DC=net
            [bindRequiresDn] => 1
        )

)
]]></programlisting>

        <para>
            The information provided in each set of options above is different mainly because AD
            does not require a username be in DN form when binding (see the
            <property>bindRequiresDn</property> option in the <emphasis>Server Options</emphasis>
            section below), which means we can omit a number of options associated with retrieving
            the DN for a username being authenticated.
        </para>

        <note>
            <title>What is a Distinguished Name?</title>

            <para>
                A DN or "distinguished name" is a string that represents the path to an object
                within the <acronym>LDAP</acronym> directory. Each comma-separated component is an
                attribute and value representing a node. The components are evaluated in reverse.
                For example, the user account
                <emphasis>CN=Bob Carter,CN=Users,DC=w,DC=net</emphasis> is located directly
                within the <emphasis>CN=Users,DC=w,DC=net container</emphasis>. This structure is
                best explored with an <acronym>LDAP</acronym> browser like the
                <acronym>ADSI</acronym> Edit <acronym>MMC</acronym> snap-in for Active Directory or
                phpLDAPadmin.
            </para>
        </note>

        <para>
            The names of servers (e.g. 'server1' and 'server2' shown above) are largely arbitrary,
            but for the sake of using <classname>Zend_Config</classname>, the identifiers should be
            present (as opposed to being numeric indexes) and should not contain any special
            characters used by the associated file formats (e.g. the '<emphasis>.</emphasis>'
            <acronym>INI</acronym> property separator, '<emphasis>&amp;</emphasis>' for
            <acronym>XML</acronym> entity references, etc).
        </para>

        <para>
            With multiple sets of server options, the adapter can authenticate users in multiple
            domains and provide failover so that if one server is not available, another will be
            queried.
        </para>

        <note>
            <title>The Gory Details: What Happens in the Authenticate Method?</title>

            <para>
                When the <methodname>authenticate()</methodname> method is called, the adapter
                iterates over each set of server options, sets them on the internal
                <classname>Zend_Ldap</classname> instance, and calls the
                <methodname>Zend_Ldap::bind()</methodname> method with the username and password
                being authenticated. The <classname>Zend_Ldap</classname> class checks to see if
                the username is qualified with a domain (e.g., has a domain component like
                <filename>alice@foo.net</filename> or <filename>FOO\alice</filename>). If a domain
                is present, but does not match either of the server's domain names
                (<filename>foo.net</filename> or <acronym>FOO</acronym>), a special exception is
                thrown and caught by <classname>Zend_Auth_Adapter_Ldap</classname> that causes that
                server to be ignored and the next set of server options is selected. If a domain
                <emphasis>does</emphasis> match, or if the user did not supply a qualified username,
                <classname>Zend_Ldap</classname> proceeds to try to bind with the supplied
                credentials. if the bind is not successful, <classname>Zend_Ldap</classname> throws
                a <classname>Zend_Ldap_Exception</classname> which is caught by
                <classname>Zend_Auth_Adapter_Ldap</classname> and the next set of server options is
                tried. If the bind is successful, the iteration stops, and the adapter's
                <methodname>authenticate()</methodname> method returns a successful result. If all
                server options have been tried without success, the authentication fails, and
                <methodname>authenticate()</methodname> returns a failure result with error messages
                from the last iteration.
            </para>
        </note>

        <para>
            The username and password parameters of the
            <classname>Zend_Auth_Adapter_Ldap</classname> constructor represent the credentials
            being authenticated (i.e., the credentials supplied by the user through your
            <acronym>HTML</acronym> login form). Alternatively, they may also be set with the
            <methodname>setUsername()</methodname> and <methodname>setPassword()</methodname>
            methods.
        </para>
    </sect2>

    <sect2 id="zend.auth.adapter.ldap.server-options">
        <title>Server Options</title>

        <para>
            Each set of server options <emphasis>in the context of
            <classname>Zend_Auth_Adapter_Ldap</classname></emphasis> consists of the following
            options, which are passed, largely unmodified, to
            <methodname>Zend_Ldap::setOptions()</methodname>:
        </para>

        <table id="zend.auth.adapter.ldap.server-options.table">
            <title>Server Options</title>

            <tgroup cols="2">
                <thead>
                    <row>
                        <entry>Name</entry>
                        <entry>Description</entry>
                    </row>
                </thead>

                <tbody>
                    <row>
                        <entry><emphasis><property>host</property></emphasis></entry>

                        <entry>
                            The hostname of <acronym>LDAP</acronym> server that these options
                            represent. This option is required.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>port</property></emphasis></entry>

                        <entry>
                            The port on which the <acronym>LDAP</acronym> server is listening. If
                            <emphasis>useSsl</emphasis> is <constant>TRUE</constant>, the default
                            <property>port</property> value is 636. If <property>useSsl</property>
                            is <constant>FALSE</constant>, the default <property>port</property>
                            value is 389.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>useStartTls</property></emphasis></entry>

                        <entry>
                            Whether or not the <acronym>LDAP</acronym> client should use
                            <acronym>TLS</acronym> (aka <acronym>SSL</acronym>v2) encrypted
                            transport. A value of <constant>TRUE</constant> is strongly favored in
                            production environments to prevent passwords from be transmitted in
                            clear text. The default value is <constant>FALSE</constant>, as servers
                            frequently require that a certificate be installed separately after
                            installation. The <property>useSsl</property> and
                            <property>useStartTls</property> options are mutually exclusive. The
                            <property>useStartTls</property> option should be favored over
                            <property>useSsl</property> but not all servers support this newer
                            mechanism.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>useSsl</property></emphasis></entry>

                        <entry>
                            Whether or not the <acronym>LDAP</acronym> client should use
                            <acronym>SSL</acronym> encrypted transport. The
                            <property>useSsl</property> and <property>useStartTls</property>
                            options are mutually exclusive, but <property>useStartTls</property>
                            should be favored if the server and <acronym>LDAP</acronym> client
                            library support it. This value also changes the default
                            <property>port</property> value (see <property>port</property>
                            description above).
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>username</property></emphasis></entry>

                        <entry>
                            The DN of the account used to perform account DN lookups.
                            <acronym>LDAP</acronym> servers that require the username to be in DN
                            form when performing the "bind" require this option. Meaning, if
                            <property>bindRequiresDn</property> is <constant>TRUE</constant>, this
                            option is required. This account does not need to be a privileged
                            account; an account with read-only access to objects under the
                            <property>baseDn</property> is all that is necessary (and preferred
                            based on the <emphasis>Principle of Least Privilege</emphasis>).
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>password</property></emphasis></entry>

                        <entry>
                            The password of the account used to perform account DN lookups. If this
                            option is not supplied, the <acronym>LDAP</acronym> client will attempt
                            an "anonymous bind" when performing account DN lookups.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>bindRequiresDn</property></emphasis></entry>

                        <entry>
                            Some <acronym>LDAP</acronym> servers require that the username used to
                            bind be in DN form like
                            <emphasis>CN=Alice Baker,OU=Sales,DC=foo,DC=net</emphasis> (basically
                            all servers <emphasis>except</emphasis> AD). If this option is
                            <constant>TRUE</constant>, this instructs
                            <classname>Zend_Ldap</classname> to automatically retrieve the DN
                            corresponding to the username being authenticated, if it is not already
                            in DN form, and then re-bind with the proper DN. The default value is
                            <constant>FALSE</constant>. Currently only Microsoft Active Directory
                            Server (<acronym>ADS</acronym>) is known <emphasis>not</emphasis> to
                            require usernames to be in DN form when binding, and therefore this
                            option may be <constant>FALSE</constant> with AD (and it should be, as
                            retrieving the DN requires an extra round trip to the server).
                            Otherwise, this option must be set to <constant>TRUE</constant> (e.g.
                            for OpenLDAP). This option also controls the default
                            <property>acountFilterFormat</property> used when searching for
                            accounts. See the <property>accountFilterFormat</property> option.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>baseDn</property></emphasis></entry>

                        <entry>
                            The DN under which all accounts being authenticated are located. This
                            option is required. if you are uncertain about the correct
                            <property>baseDn</property> value, it should be sufficient to derive it
                            from the user's <acronym>DNS</acronym> domain using
                            <emphasis>DC=</emphasis> components. For example, if the user's
                            principal name is <filename>alice@foo.net</filename>, a
                            <property>baseDn</property> of <emphasis>DC=foo,DC=net</emphasis>
                            should work. A more precise location (e.g.,
                            <emphasis>OU=Sales,DC=foo,DC=net</emphasis>) will be more efficient,
                            however.
                        </entry>
                    </row>

                    <row>
                        <entry>
                            <emphasis><property>accountCanonicalForm</property></emphasis>
                        </entry>

                        <entry>
                            A value of 2, 3 or 4 indicating the form to which account names should
                            be canonicalized after successful authentication. Values are as
                            follows: 2 for traditional username style names (e.g.,
                            <emphasis>alice</emphasis>), 3 for backslash-style names (e.g.,
                            <filename>FOO\alice</filename>) or 4 for principal style usernames
                            (e.g., <filename>alice@foo.net</filename>). The default value is 4
                            (e.g., <filename>alice@foo.net</filename>). For example, with a value
                            of 3, the identity returned by
                            <methodname>Zend_Auth_Result::getIdentity()</methodname> (and
                            <methodname>Zend_Auth::getIdentity()</methodname>, if
                            <classname>Zend_Auth</classname> was used) will always be
                            <filename>FOO\alice</filename>, regardless of what form Alice supplied,
                            whether it be <emphasis>alice</emphasis>,
                            <filename>alice@foo.net</filename>, <filename>FOO\alice</filename>,
                            <filename>FoO\aLicE</filename>, <filename>foo.net\alice</filename>,
                            etc. See the <emphasis>Account Name Canonicalization</emphasis> section
                            in the <classname>Zend_Ldap</classname> documentation for details. Note
                            that when using multiple sets of server options it is recommended, but
                            not required, that the same <property>accountCanonicalForm</property>
                            be used with all server options so that the resulting usernames are
                            always canonicalized to the same form (e.g., if you canonicalize to
                            <filename>EXAMPLE\username</filename> with an AD server but to
                            <filename>username@example.com</filename> with an OpenLDAP server, that
                            may be awkward for the application's high-level logic).
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>accountDomainName</property></emphasis></entry>

                        <entry>
                            The <acronym>FQDN</acronym> domain name for which the target
                            <acronym>LDAP</acronym> server is an authority (e.g.,
                            <filename>example.com</filename>). This option is used to canonicalize
                            names so that the username supplied by the user can be converted as
                            necessary for binding. It is also used to determine if the server is an
                            authority for the supplied username (e.g., if
                            <property>accountDomainName</property> is <filename>foo.net</filename>
                            and the user supplies <filename>bob@bar.net</filename>, the server will
                            not be queried, and a failure will result). This option is not
                            required, but if it is not supplied, usernames in principal name form
                            (e.g., <filename>alice@foo.net</filename>) are not supported. It is
                            strongly recommended that you supply this option, as there are many
                            use-cases that require generating the principal name form.
                        </entry>
                    </row>

                    <row>
                        <entry>
                            <emphasis><property>accountDomainNameShort</property></emphasis>
                        </entry>

                        <entry>
                            The 'short' domain for which the target <acronym>LDAP</acronym> server
                            is an authority (e.g., <acronym>FOO</acronym>). Note that there is a
                            1:1 mapping between the <property>accountDomainName</property> and
                            <property>accountDomainNameShort</property>. This option should be used
                            to specify the NetBIOS domain name for Windows networks, but may also
                            be used by non-AD servers (e.g., for consistency when multiple sets of
                            server options with the backslash style
                            <property>accountCanonicalForm</property>). This option is not required
                            but if it is not supplied, usernames in backslash form (e.g.,
                            <filename>FOO\alice</filename>) are not supported.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>accountFilterFormat</property></emphasis></entry>

                        <entry>
                            The <acronym>LDAP</acronym> search filter used to search for accounts.
                            This string is a <ulink
                                url="http://php.net/printf"><methodname>printf()</methodname></ulink>-style
                            expression that must contain one '<emphasis>%s</emphasis>' to
                            accomodate the username. The default value is
                            '<emphasis>(&amp;(objectClass=user)(sAMAccountName=%s))</emphasis>',
                            unless <property>bindRequiresDn</property> is set to
                            <constant>TRUE</constant>, in which case the default is
                            '<emphasis>(&amp;(objectClass=posixAccount)(uid=%s))</emphasis>'. For
                            example, if for some reason you wanted to use
                            <emphasis>bindRequiresDn = true</emphasis> with AD you would need to
                            set <emphasis>accountFilterFormat =
                                '(&amp;(objectClass=user)(sAMAccountName=%s))</emphasis>'.
                        </entry>
                    </row>

                    <row>
                        <entry><emphasis><property>optReferrals</property></emphasis></entry>

                        <entry>
                            If set to <constant>TRUE</constant>, this option indicates to the
                            <acronym>LDAP</acronym> client that referrals should be followed. The
                            default value is <constant>FALSE</constant>.
                        </entry>
                    </row>
                </tbody>
            </tgroup>
        </table>

        <note>
            <para>
                If you enable <emphasis>useStartTls = <constant>TRUE</constant></emphasis> or
                <emphasis>useSsl = <constant>TRUE</constant></emphasis> you may find that the
                <acronym>LDAP</acronym> client generates an error claiming that it cannot validate
                the server's certificate. Assuming the <acronym>PHP</acronym>
                <acronym>LDAP</acronym> extension is ultimately linked to the OpenLDAP client
                libraries, to resolve this issue you can set "<command>TLS_REQCERT never</command>"
                in the OpenLDAP client <filename>ldap.conf</filename> (and restart the web server)
                to indicate to the OpenLDAP client library that you trust the server. Alternatively,
                if you are concerned that the server could be spoofed, you can export the
                <acronym>LDAP</acronym> server's root certificate and put it on the web server so
                that the OpenLDAP client can validate the server's identity.
            </para>
        </note>
    </sect2>

    <sect2 id="zend.auth.adapter.ldap.debugging">
        <title>Collecting Debugging Messages</title>

        <para>
            <classname>Zend_Auth_Adapter_Ldap</classname> collects debugging information within its
            <methodname>authenticate()</methodname> method. This information is stored in the
            <classname>Zend_Auth_Result</classname> object as messages. The array returned by
            <methodname>Zend_Auth_Result::getMessages()</methodname> is described as follows
        </para>

        <table id="zend.auth.adapter.ldap.debugging.table">
            <title>Debugging Messages</title>

            <tgroup cols="2">
                <thead>
                    <row>
                        <entry>Messages Array Index</entry>
                        <entry>Description</entry>
                    </row>
                </thead>

                <tbody>
                    <row>
                        <entry>Index 0</entry>

                        <entry>
                            A generic, user-friendly message that is suitable for displaying to
                            users (e.g., "Invalid credentials"). If the authentication is
                            successful, this string is empty.
                        </entry>
                    </row>

                    <row>
                        <entry>Index 1</entry>

                        <entry>
                            A more detailed error message that is not suitable to be displayed to
                            users but should be logged for the benefit of server operators. If the
                            authentication is successful, this string is empty.
                        </entry>
                    </row>

                    <row>
                        <entry>Indexes 2 and higher</entry>
                        <entry>All log messages in order starting at index 2.</entry>
                    </row>
                </tbody>
            </tgroup>
        </table>

        <para>
            In practice, index 0 should be displayed to the user (e.g., using the FlashMessenger
            helper), index 1 should be logged and, if debugging information is being collected,
            indexes 2 and higher could be logged as well (although the final message always includes
            the string from index 1).
        </para>
    </sect2>

    <sect2 id="zend.auth.adapter.ldap.options-common-server-specific">
        <title>Common Options for Specific Servers</title>

        <sect3 id="zend.auth.adapter.ldap.options-common-server-specific.active-directory">
            <title>Options for Active Directory</title>

            <para>
                For <acronym>ADS</acronym>, the following options are noteworthy:
            </para>

            <table
                id="zend.auth.adapter.ldap.options-common-server-specific.active-directory.table">
                <title>Options for Active Directory</title>

                <tgroup cols="2">
                    <thead>
                        <row>
                            <entry>Name</entry>
                            <entry>Additional Notes</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry><emphasis><property>host</property></emphasis></entry>
                            <entry>As with all servers, this option is required.</entry>
                        </row>

                        <row>
                            <entry><emphasis><property>useStartTls</property></emphasis></entry>

                            <entry>
                                For the sake of security, this should be <constant>TRUE</constant>
                                if the server has the necessary certificate installed.
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>useSsl</property></emphasis></entry>

                            <entry>
                                Possibly used as an alternative to <emphasis>useStartTls</emphasis>
                                (see above).
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>baseDn</property></emphasis></entry>

                            <entry>
                                As with all servers, this option is required. By default AD places
                                all user accounts under the <emphasis>Users</emphasis> container
                                (e.g., <emphasis>CN=Users,DC=foo,DC=net</emphasis>), but the
                                default is not common in larger organizations. Ask your AD
                                administrator what the best DN for accounts for your application
                                would be.
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <emphasis><property>accountCanonicalForm</property></emphasis>
                            </entry>

                            <entry>
                                You almost certainly want this to be 3 for backslash style names
                                (e.g., <filename>FOO\alice</filename>), which are most familiar to
                                Windows users. You should <emphasis>not</emphasis> use the
                                unqualified form 2 (e.g., <emphasis>alice</emphasis>), as this may
                                grant access to your application to users with the same username in
                                other trusted domains (e.g., <filename>BAR\alice</filename> and
                                <filename>FOO\alice</filename> will be treated as the same user).
                                (See also note below.)
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <emphasis><property>accountDomainName</property></emphasis>
                            </entry>

                            <entry>
                                This is required with AD unless
                                <property>accountCanonicalForm</property> 2 is used, which, again,
                                is discouraged.
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <emphasis><property>accountDomainNameShort</property></emphasis>
                            </entry>

                            <entry>
                                The NetBIOS name of the domain that users are in and for which the
                                AD server is an authority. This is required if the backslash style
                                <property>accountCanonicalForm</property> is used.
                            </entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>

            <note>
                <para>
                    Technically there should be no danger of accidental cross-domain authentication
                    with the current <classname>Zend_Auth_Adapter_Ldap</classname> implementation,
                    since server domains are explicitly checked, but this may not be true of a
                    future implementation that discovers the domain at runtime, or if an alternative
                    adapter is used (e.g., Kerberos). In general, account name ambiguity is known to
                    be the source of security issues, so always try to use qualified account names.
                </para>
            </note>
        </sect3>

        <sect3 id="zend.auth.adapter.ldap.options-common-server-specific.openldap">
            <title>Options for OpenLDAP</title>

            <para>
                For OpenLDAP or a generic <acronym>LDAP</acronym> server using a typical
                posixAccount style schema, the following options are noteworthy:
            </para>

            <table id="zend.auth.adapter.ldap.options-common-server-specific.openldap.table">
                <title>Options for OpenLDAP</title>

                <tgroup cols="2">
                    <thead>
                        <row>
                            <entry>Name</entry>
                            <entry>Additional Notes</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry><emphasis><property>host</property></emphasis></entry>
                            <entry>As with all servers, this option is required.</entry>
                        </row>

                        <row>
                            <entry><emphasis><property>useStartTls</property></emphasis></entry>

                            <entry>
                                For the sake of security, this should be <constant>TRUE</constant>
                                if the server has the necessary certificate installed.
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>useSsl</property></emphasis></entry>

                            <entry>
                                Possibly used as an alternative to <property>useStartTls</property>
                                (see above).
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>username</property></emphasis></entry>

                            <entry>
                                Required and must be a DN, as OpenLDAP requires that usernames be
                                in DN form when performing a bind. Try to use an unprivileged
                                account.
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>password</property></emphasis></entry>

                            <entry>
                                The password corresponding to the username above, but this may be
                                omitted if the <acronym>LDAP</acronym> server permits an anonymous
                                binding to query user accounts.
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>bindRequiresDn</property></emphasis></entry>

                            <entry>
                                Required and must be <constant>TRUE</constant>, as OpenLDAP
                                requires that usernames be in DN form when performing a bind.
                            </entry>
                        </row>

                        <row>
                            <entry><emphasis><property>baseDn</property></emphasis></entry>

                            <entry>
                                As with all servers, this option is required and indicates the DN
                                under which all accounts being authenticated are located.
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <emphasis><property>accountCanonicalForm</property></emphasis>
                            </entry>

                            <entry>
                                Optional, but the default value is 4 (principal style names like
                                <filename>alice@foo.net</filename>), which may not be ideal if your
                                users are used to backslash style names (e.g.,
                                <filename>FOO\alice</filename>). For backslash style names use
                                value 3.
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <emphasis><property>accountDomainName</property></emphasis>
                            </entry>

                            <entry>
                                Required unless you're using
                                <property>accountCanonicalForm</property> 2, which is not
                                recommended.
                            </entry>
                        </row>

                        <row>
                            <entry>
                                <emphasis><property>accountDomainNameShort</property></emphasis>
                            </entry>

                            <entry>
                                If AD is not also being used, this value is not required.
                                Otherwise, if <property>accountCanonicalForm</property> 3 is used,
                                this option is required and should be a short name that corresponds
                                adequately to the <property>accountDomainName</property> (e.g., if
                                your <property>accountDomainName</property> is
                                <filename>foo.net</filename>, a good
                                <property>accountDomainNameShort</property> value might be
                                <acronym>FOO</acronym>).
                            </entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>
        </sect3>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->
