<productname>OpenLDAP</productname> as the LDAP client library, the
     <literal>ldapserver</literal> setting may be omitted.  In that case, a
     list of host names and ports is looked up via
     <ulink url="https://datatracker.ietf.org/doc/html/rfc2782">RFC 2782</ulink> DNS SRV records.
     The name <literal>_ldap._tcp.DOMAIN</literal> is looked up, where
     <literal>DOMAIN</literal> is extracted from <literal>ldapbasedn</literal>.
   </para>

   <para>
    Here is an example for a simple-bind LDAP configuration:
<programlisting>
host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
</programlisting>
    When a connection to the database server as database
    user <literal>someuser</literal> is requested, PostgreSQL will attempt to
    bind to the LDAP server using the DN <literal>cn=someuser, dc=example,
    dc=net</literal> and the password provided by the client.  If that connection
    succeeds, the database access is granted.
   </para>

   <para>
    Here is a different simple-bind configuration, which uses the LDAPS scheme
    and a custom port number, written as a URL:
<programlisting>
host ... ldap ldapurl="ldaps://ldap.example.net:49151" ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
</programlisting>
    This is slightly more compact than specifying <literal>ldapserver</literal>,
    <literal>ldapscheme</literal>, and <literal>ldapport</literal> separately.
   </para>

   <para>
    Here is an example for a search+bind configuration:
<programlisting>
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid
</programlisting>
    When a connection to the database server as database
    user <literal>someuser</literal> is requested, PostgreSQL will attempt to
    bind anonymously (since <literal>ldapbinddn</literal> was not specified) to
    the LDAP server, perform a search for <literal>(uid=someuser)</literal>
    under the specified base DN.  If an entry is found, it will then attempt to
    bind using that found information and the password supplied by the client.
    If that second bind succeeds, the database access is granted.
   </para>

   <para>
    Here is the same search+bind configuration written as a URL:
<programlisting>
host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
</programlisting>
    Some other software that supports authentication against LDAP uses the
    same URL format, so it will be easier to share the configuration.
   </para>

   <para>
    Here is an example for a search+bind configuration that uses
    <literal>ldapsearchfilter</literal> instead of
    <literal>ldapsearchattribute</literal> to allow authentication by
    user ID or email address:
<programlisting>
host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchfilter="(|(uid=$username)(mail=$username))"
</programlisting>
   </para>

   <para>
    Here is an example for a search+bind configuration that uses DNS SRV
    discovery to find the host name(s) and port(s) for the LDAP service for the
    domain name <literal>example.net</literal>:
<programlisting>
host ... ldap ldapbasedn="dc=example,dc=net"
</programlisting>
   </para>

   <tip>
    <para>
     Since LDAP often uses commas and spaces to separate the different
     parts of a DN, it is often necessary to use double-quoted parameter
     values when configuring LDAP options, as shown in the examples.
    </para>
   </tip>

  </sect1>

  <sect1 id="auth-radius">
   <title>RADIUS Authentication</title>

   <indexterm zone="auth-radius">
    <primary>RADIUS</primary>
   </indexterm>

   <para>
    This authentication method operates similarly to
    <literal>password</literal> except that it uses RADIUS
    as the password verification method. RADIUS is used only to validate
    the user name/password pairs. Therefore the user must already
    exist in the database before RADIUS can be used for
    authentication.
   </para>

   <para>