On 16 October 2015 at 01:07, Robbie Harwood <rharwood@redhat.com> wrote:
> The short - and probably most important - answer is that no, I haven't
> tested it, and it would be difficult for me to do so quickly.
IIRC it's pretty easy to fire up AWS instances that're primary domain
controllers, and then join a Pg box to them with Kerberos. I realise
that's different to having the time and desire to do it, though.
> Looking at
> http://www.postgresql.org/docs/9.4/static/protocol-message-formats.html
> suggests that SSPI follows a separate codepath from the GSS code;
> certainly it's a different auth request, which means it shouldn't
> trigger the encryption path.
It's a different auth request, but the handling in be-auth.c is
co-mingled to handle the cases:
* We're compiled with Kerberos, handling SSPI from Windows
* We're compiled with Kerberos, handling a GSSAPI request
* We're compiled with SSPI, and we're using Windows SSPI to handle a
GSSAPI auth request
* We're compiled with SSPI, and we're using it to handle a SSP client request
SSPI is a wrapper. For Windows Domain members it carries
GSSAPI/Kerberos data with the spnego extension. (For local loopback it
does NTLM, but you don't need to care about that).
> There is no reason that using GSSAPI from, e.g., MIT Kerberos for
> Windows, should not work here.
Except that *nobody* does it. The EDB installer builds Pg with SSPI,
and that's what the overwhelming majority of Windows users use.
Personally I don't care if this patch doesn't add support for GSSAPI
encryption for sspi connections, only that it doesn't break them.
> Even more broadly than that, GSSAPI is a
> RFC-standardized protocol with rigorously tested interop etc. etc.,
> though whether anyone outside of MIT cares about MIT Kerberos for
> Windows I have no idea.
It's maintained enough that AFAIK it works, and Pg supports compiling
with it. No idea if anyone tests it with Pg anymore.
> I think the important takeaway here is that I haven't actually changed
> how *authentication* works; these changes only affect GSSAPI
> post-authentication add encryption functions as defined by that
> specification. So if the authentication was working before, and the
> GSSAPI implementation is following RFC, I would hope that this would
> work still.
Hope so.
I'll put this on my "hope to test it at some stage" list, but I don't
have a prebuilt environment for it and have a lot to get ready for the
next CF, so it'll be a while...
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
