Re: "could not accept SSPI security context"

Passing null instead of empty string for the principal shouldn't make
any difference as an empty CLR-String should be marshalled to an empty
(null terminated) C-String.

The problem could also be in InitializeSecurityContext which happens in
respnse to AuthenticationGSSContinue.

If you happen to find out what the problem is - please let me know or
wrap a patch for the Npgsql development team so that we can fix it.

I'm sorry that I can't be very helpful in tracking down this issue, but
I don't have a Windows 2008 Server, or even any other Kerberos-Setup
available to test it.

Actually the SSPI-Patch was something I once put out knowing that I'll
be "bogged down by other stuff" immediatley afterwards, and it didn't
see much maintainace since then.
There are some oversights like

// TODO: correct exception
throw new Exception();

in NpgsqlState.cs and the fact that the Continue method (in
SSPIHandler.cs) returns the (opaque) secbuffer as ASCII-String (encoded
by System.Text.Encoding.ASCII.GetString(Byte[])) should even be
considered as a bug (even though to my knowledge it didn't cause any
problems until now).

In other words - I'd be willing to overhaul the wohle thing if I find a
good reason to do so (and some time).

Regards,

Brar

On Fri, 3 Dec 2010 06:32:17 +0100, Reto Schöning
<reto(dot)schoening(at)gmail(dot)com> wrote:
> thanks, and sorry for my slow responses, I'm bogged down by other
> stuff. I plan to get the source and try some things like
> - force kerberos to see if the reason that NTLM is used is that
> kerberos fails and hope for some hints at the cause of the failure
> - pass null instead of empty string for the principal
> - check out the principal on the calling thread etc.
> and post the results to the list. Could take I week or so until a get
> to that though.
> Regards, Reto
>
> 2010/11/29 Brar Piening <brar(at)gmx(dot)de <mailto:brar(at)gmx(dot)de>>
>
> On Mon, 29 Nov 2010 15:27:35 +0100, Reto Schöning
> <reto(dot)schoening(at)gmail(dot)com <mailto:reto(dot)schoening(at)gmail(dot)com>> wrote:
>
> I just heard back from our IT. There's nothing in the logs for
> this connection attempt, but they noted in the Npgsql log that
> the authentication was attempted using NTLM. However our
> domain controller no longer supports NTLM, but only LDAP(s)
> and kerberos (it's a Windows 2008 server). From the docs I
> understand that with SSPI, pg should try kerberos first and
> fall back to NTLM. This works when connecting from psql. Maybe
> Npgsql goes straight for NTLM, at least when using it the way
> I do?
>
>
> Both are using the Negotiate SSP authentication package
>
> http://msdn.microsoft.com/en-us/library/aa378748%28v=VS.85%29.aspx
>
> Npgsql (SSPIHandler.cs):
> int status = AcquireCredentialsHandle(
> "",
> "negotiate",
> SECPKG_CRED_OUTBOUND,
> IntPtr.Zero,
> IntPtr.Zero,
> IntPtr.Zero,
> IntPtr.Zero,
> ref sspicred,
> out expire
> );
>
> libpq (fe-auth.c):
> /*
> * Send initial SSPI authentication token.
> * If use_negotiate is 0, use kerberos authentication package which is
> * compatible with Unix. If use_negotiate is 1, use the negotiate
> package
> * which supports both kerberos and NTLM, but is not compatible
> with Unix.
> */
> r = AcquireCredentialsHandle(NULL,
> use_negotiate ? "negotiate" : "kerberos",
> SECPKG_CRED_OUTBOUND,
> NULL,
> NULL,
> NULL,
> NULL,
> conn->sspicred,
> &expire);
>
> It should be a one line patch to force Npgsql into using kerberos
> but I can't see any reason why negotiate should act differently
> between Npgsql and libpq.
>
> Regards,
>
> Brar
>
>