Re: "could not accept SSPI security context"

-------- Original Message --------
Subject: Re: [GENERAL] "could not accept SSPI security context"
From: Reto Schöning <reto(dot)schoening(at)gmail(dot)com>
To: Brar Piening <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-AUTH
is correct by stating that "The name of the service principal is
/servicename///hostname/@/realm/. " 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