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