On Fri, Jan 15, 2016 at 9:46 PM, Christian Ullrich <chris@chrullrich.net> wrote:
* Christian Ullrich wrote:
* Christian Ullrich wrote:
* Christian Ullrich wrote:
> According to the release notes, the default for the "include_realm" > option in SSPI authentication was changed from off to on in 9.5 for
> > improved security. However, the authenticated user name, with the > > option enabled, includes the NetBIOS domain name, *not* the Kerberos
> realm name:
Below is a patch to correct this behavior. I suspect it has some serious compatibility issues, so I would appreciate feedback.
Updated patch, sorry. The first one worked by accident only.
Another update. This time even the documentation builds.
One thing I'm fairly sure I need advice on is error handling and/or error codes. Right now I use ERROR_INVALID_ROLE_SPECIFICATION just about everywhere (because the surrounding SSPI code does as well), and that is probably not the best choice in some places.
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).
How does the real_realm thing work if you connect with a local account? Hostname, or kerberos principal for the host?
Code uses a mix of malloc() and palloc() (through sprintf). Is there a reason for that?
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?)
