* 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
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 (email@example.com)
To make changes to your subscription: