Re: BUG #13854: SSPI authentication failure: wrong realm name used

* From: Magnus Hagander [mailto:magnus(at)hagander(dot)net]

> I took a quick look at this one, and have some initial thoughts.
>
> I don't like the name "real_realm" as a parameter name. I'm wondering if
> it might be better to reverse the meaning, and call it sspi_netbios_realm
> (and then change the default to on, to be backwards compatible).

What about "compat_realm" instead? "sspi_netbios_realm" is a bit long.
Also, the domain short name is not really a realm name, and this would
feel like implying that it is.

> How does the real_realm thing work if you connect with a local account?
> Hostname, or kerberos principal for the host?

It fails. There is no UPN with a local account, so the conversion does not
happen, and I thought it would be best from a security POV to let the logon
fail rather than inventing a reason why it should succeed.

> Code uses a mix of malloc() and palloc() (through sprintf). Is there a
> reason for that?

I wasn't sure which to prefer, so I looked around in auth.c, and other than
RADIUS, everything seems to use malloc() (although the sample size is not
too great). Should I use palloc() instead?

> Looking at the docs:
>
> + Note that <application>libpq</> uses the SAM-compatible name if
> no
> + explicit user name is specified. If you use
> + <application>libpq</> (e.g. through the ODBC driver), you should
> + leave this option disabled.
>
> What's the actual usecase where it makes sense to change it? Seems that's
> the more reasonable thing to document, with a reference to active
> directory specifically (or is there also such a compatible name for local
> accounts?)

In an environment where sAMAccountName and userPrincipalName are different,
it might be preferable to have something to map in pg_ident.conf that is
actually a valid user name (UPN, in this case), rather than a mixture of
both forms that isn't valid for either.

Also, since I already have the UPN, adding the option is basically free and
feels more useful than always throwing away half the information.

Another thing: This business of getting a SID, turning it into a user
name/domain pair, then using that to get the UPN (which probably involves
converting it to the SID again somewhere in between) does not look very good
to me. I'll have to see if it works, but what do you think about briefly
impersonating the client, just long enough to get the SAM and UPN names?

--
Christian