* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Here's an updated version of this patch. This version has full SSPI support
> in the server as well, so I can do both kerberos and NTLM between two
> windows machines using the negotiate method.

Great!  Also, I've tested that it works under Windows using
PGGSSLIB=gssapi with the MIT GSS libraries.  I did have to set the
PGKRBSRVNAME to 'postgres'.  It worked excellently. :)

> Since SSPI and GSSAPI can now both be used, my plan is not to have an
> autoconf to disable SSPI, but to just enable it unconditionally on win32.
> Or does this seem like a bad idea?

My thinking would be to have the autoconf to disable it, but enable it
by default.  I don't feel particularly strongly about it though.

> Comments welcome.

It looks good in general to me (though I'm not super-familiar with
SSPI).  My one big concern is this:

>   /* Define to the name of the default PostgreSQL service principal in 
> Kerberos.
>      (--with-krb-srvnam=NAME) */
> ! #define PG_KRB_SRVNAM "postgres"
>   
>   /* A string containing the version number, platform, and C compiler */
>   #define PG_VERSION_STR "Uninitialized version string (win32)"
> --- 582,588 ----
>   
>   /* Define to the name of the default PostgreSQL service principal in 
> Kerberos.
>      (--with-krb-srvnam=NAME) */
> ! #define PG_KRB_SRVNAM "POSTGRES"

I understand that SSPI is case-insensitive, or folds to uppercase, or
whatever, but this is *not* used only by the SSPI code.  Please correct
me if I'm wrong, but this will break existing krb-auth using client
applications/setups that went with the previous default, no?  I realize
it's on Windows, but there are people out there with that
configuration (yes, like me... :)...

I don't particularly like it but, honestly, it seems like it might be
better to set it based on what's being used (GSSAPI/SSPI/KRB5)?  This
would be for the client-side, as I guess we've decided it's okay to just
pick whatever keytab the users provide that's in our server-side
keytab.

        Thanks again!

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to