Re: "could not accept SSPI security context"

ok we moved to VS08 and I can at last experiment with the npgsql code. I
tried forcing "kerberos" instead of "negotiate" in the call to
AcquireCredentialsHandle in SSPIHandler.cs. The exception message I then get
in the first call to InitializeSecurityContext() is

"The security database on the server does not have a computer account for
this workstation trust relationship"

googling that yields AD configuration issues as a possible cause (eg
http://social.technet.microsoft.com/Forums/en-US/itprovistasp/thread/31905c1a-5c25-4426-ac8d-677004c21f5d).
I will check that with our IT. However since from the same machines, psql
and other pg clients can successfully connect using kerberos, an AD issue
seems unlikely to be the (sole) cause.

I also speculated that the CurrentPrincipal on the thread might matter and
made sure that it was the kerberos-authenticated WindowsPrincipal, instead
of the default GenericPrincipal. But that made no difference.

Is there anything else in the code that I could check or try?
Regards,
Reto

2010/12/3 Brar Piening <brar(at)gmx(dot)de>

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