From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christian Ullrich <chris(at)chrullrich(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Initial release notes created for 9.6 |
Date: | 2016-05-06 20:07:35 |
Message-ID: | 8390.1462565255@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christian Ullrich <chris(at)chrullrich(dot)net> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-05-06 20:07:54 | Re: pgsql: Add TAP tests for pg_dump |
Previous Message | Alvaro Herrera | 2016-05-06 20:03:33 | Re: Feature request: make cluster_name GUC useful for psql prompts |