On 16 October 2015 at 01:07, Robbie Harwood <rharw...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers