authentication method is
    therefore only appropriate for closed networks where each client
    machine is under tight control and where the database and system
    administrators operate in close contact. In other words, you must
    trust the machine running the ident server.
    Heed the warning:
    <blockquote>
     <attribution>RFC 1413</attribution>
     <para>
      The Identification Protocol is not intended as an authorization
      or access control protocol.
     </para>
    </blockquote>
   </para>

   <para>
    Some ident servers have a nonstandard option that causes the returned
    user name to be encrypted, using a key that only the originating
    machine's administrator knows.  This option <emphasis>must not</emphasis> be
    used when using the ident server with <productname>PostgreSQL</productname>,
    since <productname>PostgreSQL</productname> does not have any way to decrypt the
    returned string to determine the actual user name.
   </para>
  </sect1>

  <sect1 id="auth-peer">
   <title>Peer Authentication</title>

   <indexterm>
    <primary>peer</primary>
   </indexterm>

   <para>
    The peer authentication method works by obtaining the client's
    operating system user name from the kernel and using it as the
    allowed database user name (with optional user name mapping). This
    method is only supported on local connections.
   </para>

   <para>
    The following configuration options are supported for <literal>peer</literal>:
    <variablelist>
     <varlistentry>
      <term><literal>map</literal></term>
      <listitem>
       <para>
        Allows for mapping between system and database user names. See
        <xref linkend="auth-username-maps"/> for details.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>

   <para>
    Peer authentication is only available on operating systems providing
    the <function>getpeereid()</function> function, the <symbol>SO_PEERCRED</symbol>
    socket parameter, or similar mechanisms.  Currently that includes
    <systemitem class="osname">Linux</systemitem>,
    most flavors of <systemitem class="osname">BSD</systemitem> including
    <systemitem class="osname">macOS</systemitem>,
    and <systemitem class="osname">Solaris</systemitem>.
   </para>

  </sect1>

  <sect1 id="auth-ldap">
   <title>LDAP Authentication</title>

   <indexterm zone="auth-ldap">
    <primary>LDAP</primary>
   </indexterm>

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

   <para>
    LDAP authentication can operate in two modes. In the first mode,
    which we will call the simple bind mode,
    the server will bind to the distinguished name constructed as
    <replaceable>prefix</replaceable> <replaceable>username</replaceable> <replaceable>suffix</replaceable>.
    Typically, the <replaceable>prefix</replaceable> parameter is used to specify
    <literal>cn=</literal>, or <replaceable>DOMAIN</replaceable><literal>\</literal> in an Active
    Directory environment.  <replaceable>suffix</replaceable> is used to specify the
    remaining part of the DN in a non-Active Directory environment.
   </para>

   <para>
    In the second mode, which we will call the search+bind mode,
    the server first binds to the LDAP directory with
    a fixed user name and password, specified with <replaceable>ldapbinddn</replaceable>
    and <replaceable>ldapbindpasswd</replaceable>, and performs a search for the user trying
    to log in to the database. If no user and password is configured, an
    anonymous bind will be attempted to the directory. The search will be
    performed over the subtree at <replaceable>ldapbasedn</replaceable>, and will try to
    do an