Re: Initial release notes created for 9.6

Christian Ullrich <chris@chrullrich.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</>,
tocontrol whether NetBIOS or Kerberos       realm names and user names are used during SSPI authentication
(ChristianUllrich)      </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'sSAM-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
virtualservice 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