sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-30 00:02:11 -04:00
Code Issues Projects Releases Wiki Activity

Docs: minor copy-editing for GSSAPI/SSPI authentication docs.

Browse Source 
Describe compat_realm = 0 as "disabled" not "enabled", per discussion
with Christian Ullrich.  I failed to resist the temptation to do some
other minor copy-editing in the same area.
This commit is contained in:
Tom Lane 2016-05-06 17:42:44 -04:00
parent 6e243c43c9
commit 36db18eaa0
1 changed files with 20 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
doc/src/sgml/client-auth.sgml
View File

@ -970,17 +970,18 @@ omicron bryanh guest1
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</> to 0. For simple single-realm
installations, <literal>include_realm</> combined with the
<literal>krb_realm</> parameter (which checks that the realm provided
matches exactly what is in the <literal>krb_realm</literal> parameter) would be a secure but
less capable option compared to specifying an explicit mapping in
installations, doing that combined with setting the
<literal>krb_realm</> 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</>.
</para>
<para>
Make sure that your server keytab file is readable (and preferably
only readable) by the <productname>PostgreSQL</productname> server
account. (See also <xref linkend="postgres-user">.) The location
only readable, not writable) by the <productname>PostgreSQL</productname>
server account. (See also <xref linkend="postgres-user">.) The location
of the key file is specified by the <xref
linkend="guc-krb-server-keyfile"> configuration
parameter. The default is
@ -1019,10 +1020,12 @@ omicron bryanh guest1
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. Users
are recommended to leave include_realm set to the default (1) and to
provide an explicit mapping in <filename>pg_ident.conf</>.
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</> to convert
principal names to <productname>PostgreSQL</> user names.
</para>
</listitem>
</varlistentry>
@ -1098,10 +1101,12 @@ omicron bryanh guest1
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. Users
are recommended to leave include_realm set to the default (1) and to
provide an explicit mapping in <filename>pg_ident.conf</>.
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</> to convert
principal names to <productname>PostgreSQL</> user names.
</para>
</listitem>
</varlistentry>
@ -1116,7 +1121,7 @@ omicron bryanh guest1
the Kerberos user principal name is used.
</para>
<para>
Do not enable this option unless your server runs under a domain
Do not disable this option unless your server runs under a domain
account (this includes virtual service accounts on a domain member
system) and all clients authenticating through SSPI are also using
domain accounts, or authentication will fail.