-------- Original Message --------
Subject: Re: [GENERAL] "could not accept SSPI security context"
From: Reto Schöning
<reto.schoening@gmail.com> To: Brar Piening
<brar@gmx.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