Re: "could not accept SSPI security context"

thanks a lot for the hints.

All connections I tried used the IP address of the pg server. Also the
service name should be the default one.

I tried setting the sspitarget in SSPIHandler.cs to all sorts of variations,
including fully qualified names. The error remains exactly the same, even
when I set sspitarget to nonsensical values.
I'll discuss this with our IT in january. Maybe there IS some inconsistency
in those AD accounts, only that the authentication from libpq can cope with
that. From afar it seems that the calls to AcquireCredentialsHandle() and
InitializeSecurityContext() in npgsql and libpq do the same thing though.

Regards, Reto

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

> -------- Original Message --------
> Subject: Re: [GENERAL] "could not accept SSPI security context"
> From: Reto Schöning <reto(dot)schoening(at)gmail(dot)com> <reto(dot)schoening(at)gmail(dot)com>
> To: Brar Piening <brar(at)gmx(dot)de> <brar(at)gmx(dot)de>
> Date: 22.12.2010 17:08
>
>
> "The security database on the server does not have a computer account for
> this workstation trust relationship"
>
> [...]
>
> Is there anything else in the code that I could check or try?
>
>
> Did you make sure that all connection parameters are the same between libpq
> clients (psql, PgAdmin, ...) and Npgsql?
>
> Also on my computer PgAdmin fails to connect if I try to connect to
> "localhost" instead of "127.0.0.1" via SSPI while connecting (some test app)
> via Npgsql will work (by internally using the ip addresses in
> Socket.RemoteEndPoint.Address instead of the host name).
> This could lead to the fact that a Npgsql program uses a different Kerberos
> service principal than you might think as it uses the first working ip
> address from Dns.GetHostAddresses as hostname part.
> What bothers me about this is that if
> http://www.postgresql.org/docs/current/static/auth-methods.html#KERBEROS-AUTHis correct by stating that "The name of the service principal is
> *servicename*/*hostname*(at)*realm*(dot) " and "*hostname* is the fully qualified
> host name of the server machine." connecting via host name should work in
> principle while it doesn't on my machine (actually using NTLM).
>
> One other thing that comes to mind is the fact that Npgsql is currently
> hardcoded to use "POSTGRES" as Kerberos service name while in libpq this can
> be changed as a compile time option, a server configuration parameter and a
> connection parameter setting.
> Still this is an unlikely cause if you didn't fiddle around with this in
> psql as the PostgreSQL docs state: " In most environments, this parameter
> never needs to be changed. However, it is necessary when supporting multiple
> PostgreSQL installations on the same host. Some Kerberos implementations
> might also require a different service name, such as Microsoft Active
> Directory which requires the service name to be in upper case (POSTGRES).
> "
>
> Sorry for those pretty random amateurish guesses but I've got zero Kerberos
> experience and not even a kerberos setup to test with.
>
> Best Regards,
>
> Brar
>