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