file can be used
    to map principals to user names; for example,
    <literal>pgusername@realm</literal> could be mapped to just <literal>pgusername</literal>.
    Alternatively, you can use the full <literal>username@realm</literal> principal as
    the role name in <productname>PostgreSQL</productname> without any mapping.
   </para>

   <para>
    <productname>PostgreSQL</productname> also supports mapping
    client principals to user names by just stripping the realm from
    the principal.  This method is supported for backwards compatibility and is
    strongly discouraged as it is then impossible to distinguish different users
    with the same user name but coming from different realms.  To enable this,
    set <literal>include_realm</literal> to 0.  For simple single-realm
    installations, doing that combined with setting the
    <literal>krb_realm</literal> parameter (which checks that the principal's realm
    matches exactly what is in the <literal>krb_realm</literal> parameter)
    is still secure; but this is a
    less capable approach compared to specifying an explicit mapping in
    <filename>pg_ident.conf</filename>.
   </para>

   <para>
    The location of the server's keytab file is specified by the <xref
    linkend="guc-krb-server-keyfile"/> configuration parameter.
    For security reasons, it is recommended to use a separate keytab
    just for the <productname>PostgreSQL</productname> server rather
    than allowing the server to read the system keytab file.
    Make sure that your server keytab file is readable (and preferably
    only readable, not writable) by the <productname>PostgreSQL</productname>
    server account.  (See also <xref linkend="postgres-user"/>.)
   </para>

   <para>
    The keytab file is generated using the Kerberos software; see the
    Kerberos documentation for details. The following example shows
    doing this using the <application>kadmin</application> tool of
    MIT Kerberos:
<screen>
<prompt>kadmin% </prompt><userinput>addprinc -randkey postgres/server.my.domain.org</userinput>
<prompt>kadmin% </prompt><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</userinput>
</screen>
   </para>

   <para>
    The following authentication options are supported for
    the <productname>GSSAPI</productname> authentication method:
    <variablelist>
     <varlistentry>
      <term><literal>include_realm</literal></term>
      <listitem>
       <para>
        If set to 0, the realm name from the authenticated user principal is
        stripped off before being passed through the user name mapping
        (<xref linkend="auth-username-maps"/>). This is discouraged and is
        primarily available for backwards compatibility, as it is not secure
        in multi-realm environments unless <literal>krb_realm</literal> is
        also used.  It is recommended to
        leave <literal>include_realm</literal> set to the default (1) and to
        provide an explicit mapping in <filename>pg_ident.conf</filename> to convert
        principal names to <productname>PostgreSQL</productname> user names.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>map</literal></term>
      <listitem>
       <para>
        Allows mapping from client principals to database user names. See
        <xref linkend="auth-username-maps"/> for details.  For a GSSAPI/Kerberos
        principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
        commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
        user name used for mapping is
        <literal>username@EXAMPLE.COM</literal> (or
        <literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
        unless <literal>include_realm</literal> has been set to 0, in which case
        <literal>username</literal> (or <literal>username/hostbased</literal>)
        is what is seen as the system user name when mapping.
       </para>
      </listitem>
     </varlistentry>