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