Re: "could not accept SSPI security context" - Mailing list pgsql-general

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.schoening@gmail.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@gmx.de>

On Mon, 29 Nov 2010 15:27:35 +0100, Reto Schöning <reto.schoening@gmail.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