Christian Ullrich <[email protected]> writes:
> * Tom Lane wrote:
> + <para>
> + Add new SSPI authentication parameters <varname>compat_realm</>
> + and <varname>upn_usename</>, to make it possible to make SSPI
> + work more like GSSAPI (Christian Ullrich)
> + </para>
> It is upn_username, not usename. Typo in the commit message.
> "Make SSPI work more like GSSAPI" reads like it changed authentication
> behavior in some fundamental way, and as if SSPI did not work like
> GSSAPI without it. The difference in behavior of include_realm between
> GSSAPI and SSPI is not caused by SSPI, but is an implementation detail
> on our end.
> I suggest writing "use the Kerberos realm name for authentication
> instead of the NetBIOS name" either in place of the existing description
> or together with it.
OK, how about this:
<para>
Add new SSPI authentication parameters <varname>compat_realm</>
and <varname>upn_username</>, to control whether NetBIOS or Kerberos
realm names and user names are used during SSPI authentication
(Christian Ullrich)
</para>
BTW, I went to read the descriptions of those parameters again, and this
one seems a bit confusing:
<varlistentry>
<term><literal>compat_realm</literal></term>
<listitem>
<para>
If set to 1, the domain's SAM-compatible name (also known as the
NetBIOS name) is used for the <literal>include_realm</literal>
option. This is the default. If set to 0, the true realm name from
the Kerberos user principal name is used.
</para>
<para>
Do not enable 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.
</para>
</listitem>
</varlistentry>
To my mind, an option that's set to 1 is "enabled". Should the second
para read "Do not disable ..."? Or maybe we should reverse the sense
of the flag, so that the default state can be 0 == disabled?
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
