* Tom Lane wrote:

Christian Ullrich <ch...@chrullrich.net> writes:

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:

        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)

Perfect, except for the implied idea of a "NetBIOS realm name", see below. I can live with that in release notes, though.

BTW, I went to read the descriptions of those parameters again, and this
one seems a bit confusing:

        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.
        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.

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?

Well spotted, thanks. It should be "disable" instead.

This is left from when the sense of the option _was_ the other way around (it was called "real_realm" then). I reversed and renamed it after Magnus reviewed the patch and was -- correctly -- opposed to the name.

If the default state should be off, we're back to inventing a useful new name. Magnus suggested "sspi_netbios_realm", which could be shortened to just "netbios_realm", but I don't like to have both "NetBIOS" and "realm" in the name because nobody else calls a domain's NetBIOS name a "realm". (For the release notes, on the other hand, there is no need to split this hair quite so thin.)

Unless you _really_ want the default (that is, backwards compatible) behavior with the option off, I would rather keep it the way it is.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to