Christian Ullrich <ch...@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</>, 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to