"could not accept SSPI security context"

On Mon, Nov 22, 2010 at 10:21, Reto Schöning <reto.schoening@gmail.com> wrote:

Hi,

I've set up 8.3 to use SSPI for authentication (clients and server on
windows XP). I can successfully connect from clients using psql and another
db client using SSPI authentication. However when trying to connect with
Npgsql (2.0.11) as the same user, the following error occurs:

   "could not accept SSPI security context"

The same type of connection succeeds when connecting locally from the db
server. The problem only affects connection attempts on client machines, and
(currently) only when connecting from a .Net application using
Npgsql. However the same error also showed up when connecting with psql
initially. Now that works, and I'm not sure what change made that error
disappear.
Can anyone help me understand that error? What circumstances can lead to
this?

There should be a details row associated with that message that should
give you some further hints on what actually went wrong.

You should probably post this to the npgsql list as well, since it
does seem to be an npgsql problem - as you say, it works from psql
which means it works from libpq.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Plase don't drop the mailinglist from the thread.

On Mon, Nov 22, 2010 at 11:57, Reto Schöning <reto.schoening@gmail.com> wrote:

Thanks for the hint. The full error message from npgsql including that
detail row is
Npgsql.NpgsqlException was unhandled
  Message="FATAL: XX000: could not accept SSPI security context"
  Source="Npgsql"
  ErrorCode=-2147467259
  BaseMessage="could not accept SSPI security context"
  Code="XX000"
  Detail="The logon attempt failed\r\n (8009030c)"
  ErrorSql=""
  File=".\\src\\backend\\libpq\\auth.c"
  Hint=""
  Line="648"
  Position=""
  Routine="pg_SSPI_error"
  Severity="FATAL"
  Where=""
  StackTrace:
       at Npgsql.NpgsqlState.<ProcessBackendResponses_Ver_3>d__a.MoveNext()
in C:\projects\Npgsql2\src\Npgsql\NpgsqlState.cs:line 686
       at Npgsql.NpgsqlState.IterateThroughAllResponses(IEnumerable`1 ienum)
in C:\projects\Npgsql2\src\Npgsql\NpgsqlState.cs:line 319
       at Npgsql.NpgsqlState.ProcessBackendResponses(NpgsqlConnector
context) in C:\projects\Npgsql2\src\Npgsql\NpgsqlState.cs:line 314
       at Npgsql.NpgsqlConnectedState.Startup(NpgsqlConnector context) in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectedState.cs:line 52
       at Npgsql.NpgsqlConnector.Open() in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnector.cs:line 656
       at Npgsql.NpgsqlConnectorPool.GetPooledConnector(NpgsqlConnection
Connection) in C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
423
       at
Npgsql.NpgsqlConnectorPool.RequestPooledConnectorInternal(NpgsqlConnection
Connection) in C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
226
       at Npgsql.NpgsqlConnectorPool.RequestPooledConnector(NpgsqlConnection
Connection) in C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
178
       at Npgsql.NpgsqlConnectorPool.RequestConnector(NpgsqlConnection
Connection) in C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
158
       at Npgsql.NpgsqlConnection.Open() in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnection.cs:line 543
       at NpgsqlTest.Program.Main(String[] args) in C:\Documents and
Settings\rsc\My Documents\Visual Studio
2005\Projects\NpgsqlTest\NpgsqlTest\Program.cs:line 17
I found a way to reproduce the same message in psql: when creating a local
user with the same name as a domain user, the connection attempt when logged
in as that user fails with the same message (rightly so, of course).
I've posted that in the npgsql forum also, no response yet.

The details row you're looking for is in the *server* side log.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Here's the log output for a failed connection:

2010-11-22 13:25:54 CET FATAL: could not accept SSPI security context
2010-11-22 13:25:54 CET DETAIL: The logon attempt failed
(8009030c)

2010/11/22 Magnus Hagander <magnus@hagander.net>

Hmm. That's a simple SEC_E_LOGON_DENIED. Simply meaning
usedname/password is incorrect. The security eventlog on the server
(or domain controller) might have more information around it. If not,
I'm not sure what's wrong there - if it happens only in npgsql it must
be related to that. Or perhaps - based on your reproduction - the .net
app is running with a different user than you think?

//Magnus

On Mon, Nov 22, 2010 at 13:31, Reto Schöning <reto.schoening@gmail.com> wrote:

Here's the log output for a failed connection:
2010-11-22 13:25:54 CET FATAL:  could not accept SSPI security context
2010-11-22 13:25:54 CET DETAIL:  The logon attempt failed
(8009030c)

2010/11/22 Magnus Hagander <magnus@hagander.net>

Plase don't drop the mailinglist from the thread.

On Mon, Nov 22, 2010 at 11:57, Reto Schöning <reto.schoening@gmail.com>
wrote:

Thanks for the hint. The full error message from npgsql including that
detail row is
Npgsql.NpgsqlException was unhandled
  Message="FATAL: XX000: could not accept SSPI security context"
  Source="Npgsql"
  ErrorCode=-2147467259
  BaseMessage="could not accept SSPI security context"
  Code="XX000"
  Detail="The logon attempt failed\r\n (8009030c)"
  ErrorSql=""
  File=".\\src\\backend\\libpq\\auth.c"
  Hint=""
  Line="648"
  Position=""
  Routine="pg_SSPI_error"
  Severity="FATAL"
  Where=""
  StackTrace:
       at
Npgsql.NpgsqlState.<ProcessBackendResponses_Ver_3>d__a.MoveNext()
in C:\projects\Npgsql2\src\Npgsql\NpgsqlState.cs:line 686
       at Npgsql.NpgsqlState.IterateThroughAllResponses(IEnumerable`1
ienum)
in C:\projects\Npgsql2\src\Npgsql\NpgsqlState.cs:line 319
       at Npgsql.NpgsqlState.ProcessBackendResponses(NpgsqlConnector
context) in C:\projects\Npgsql2\src\Npgsql\NpgsqlState.cs:line 314
       at Npgsql.NpgsqlConnectedState.Startup(NpgsqlConnector context)
in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectedState.cs:line 52
       at Npgsql.NpgsqlConnector.Open() in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnector.cs:line 656
       at Npgsql.NpgsqlConnectorPool.GetPooledConnector(NpgsqlConnection
Connection) in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
423
       at

Npgsql.NpgsqlConnectorPool.RequestPooledConnectorInternal(NpgsqlConnection
Connection) in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
226
       at
Npgsql.NpgsqlConnectorPool.RequestPooledConnector(NpgsqlConnection
Connection) in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
178
       at Npgsql.NpgsqlConnectorPool.RequestConnector(NpgsqlConnection
Connection) in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line
158
       at Npgsql.NpgsqlConnection.Open() in
C:\projects\Npgsql2\src\Npgsql\NpgsqlConnection.cs:line 543
       at NpgsqlTest.Program.Main(String[] args) in C:\Documents and
Settings\rsc\My Documents\Visual Studio
2005\Projects\NpgsqlTest\NpgsqlTest\Program.cs:line 17
I found a way to reproduce the same message in psql: when creating a
local
user with the same name as a domain user, the connection attempt when
logged
in as that user fails with the same message (rightly so, of course).
I've posted that in the npgsql forum also, no response yet.

The details row you're looking for is in the *server* side log.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Mon, 22 Nov 2010 13:43:14 +0100, Magnus Hagander
<magnus@hagander.net> wrote:

Hmm. That's a simple SEC_E_LOGON_DENIED. Simply meaning
usedname/password is incorrect. The security eventlog on the server
(or domain controller) might have more information around it. If not,
I'm not sure what's wrong there - if it happens only in npgsql it must
be related to that. Or perhaps - based on your reproduction - the .net
app is running with a different user than you think?

If you've got access to the sources of your client app that uses Npgsql
you might want to put :

NpgsqlEventLog.Level = LogLevel.Debug;
NpgsqlEventLog.LogName = @"C:\somePath\NpgsqlEventLog.txt";

in the code before the first call of NpgsqlConnection.Open() to find out
details about the user name that's actually connecting.

Just look for

Entering PGUtil.WriteString()
String written: user.
Entering PGUtil.WriteString()
String written: YOURCONNECTINGUSERNAME.

after

Entering NpgsqlStartupPacket.NpgsqlStartupPacket()
Entering NpgsqlStartupPacket.WriteToStream()
Entering NpgsqlStartupPacket.WriteToStream_Ver_3()

Regards,

Brar

thanks a lot for the hints.

client side logging: the user name corresponds to the expected user, without
the domain prefix ("rsc"). See the full log output below.

security event log: I should get that shortly from our IT.
Regards, Reto

29.11.2010 10:37:17 4412 Debug Entering
NpgsqlConnection.NpgsqlConnection(NpgsqlConnection())
29.11.2010 10:37:18 4412 Debug ConnectionString Option: HOST = <ip>
29.11.2010 10:37:18 4412 Debug ConnectionString Option: PORT = 5432
29.11.2010 10:37:18 4412 Debug ConnectionString Option: PROTOCOL = 3
29.11.2010 10:37:18 4412 Debug ConnectionString Option: DATABASE = some_db
29.11.2010 10:37:18 4412 Debug ConnectionString Option: USER ID =
29.11.2010 10:37:18 4412 Debug ConnectionString Option: PASSWORD =
29.11.2010 10:37:18 4412 Debug ConnectionString Option: SSL = False
29.11.2010 10:37:18 4412 Debug ConnectionString Option: SSLMODE = Disable
29.11.2010 10:37:18 4412 Debug ConnectionString Option: TIMEOUT = 15
29.11.2010 10:37:18 4412 Debug ConnectionString Option: SEARCHPATH =
29.11.2010 10:37:18 4412 Debug ConnectionString Option: POOLING = True
29.11.2010 10:37:18 4412 Debug ConnectionString Option: CONNECTIONLIFETIME =
15
29.11.2010 10:37:18 4412 Debug ConnectionString Option: MINPOOLSIZE = 1
29.11.2010 10:37:18 4412 Debug ConnectionString Option: MAXPOOLSIZE = 20
29.11.2010 10:37:18 4412 Debug ConnectionString Option: SYNCNOTIFICATION =
False
29.11.2010 10:37:18 4412 Debug ConnectionString Option: COMMANDTIMEOUT = 20
29.11.2010 10:37:18 4412 Debug ConnectionString Option: ENLIST = False
29.11.2010 10:37:18 4412 Debug ConnectionString Option: PRELOADREADER =
False
29.11.2010 10:37:18 4412 Debug ConnectionString Option: USEEXTENDEDTYPES =
False
29.11.2010 10:37:18 4412 Debug ConnectionString Option: INTEGRATED SECURITY
= true
29.11.2010 10:37:18 4412 Debug ConnectionString Option: COMPATIBLE =
2.0.11.0
29.11.2010 10:37:18 4412 Debug Entering NpgsqlConnection.Open()
29.11.2010 10:37:18 4412 Debug Get NpgsqlClosedState.Instance
29.11.2010 10:37:18 4412 Debug Get NpgsqlClosedState.Instance
29.11.2010 10:37:18 4412 Debug Entering NpgsqlClosedState.Open()
29.11.2010 10:37:19 4412 Debug Attempt to connect to '<ip>'.
29.11.2010 10:37:19 4412 Normal Connected to: <ip>:5432.
29.11.2010 10:37:19 4412 Debug Entering
NpgsqlStartupPacket.NpgsqlStartupPacket()
29.11.2010 10:37:19 4412 Debug Entering NpgsqlStartupPacket.WriteToStream()
29.11.2010 10:37:19 4412 Debug Entering
NpgsqlStartupPacket.WriteToStream_Ver_3()
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: user.
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: rsc.
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: database.
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: some_db.
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: DateStyle.
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: ISO.
29.11.2010 10:37:19 4412 Debug Entering
NpgsqlState.ProcessBackendResponses()
29.11.2010 10:37:19 4412 Debug AuthenticationRequest message received from
server.
29.11.2010 10:37:19 4412 Debug Entering NpgsqlStartupState.Authenticate()
29.11.2010 10:37:19 4412 Debug Entering
NpgsqlPasswordPacket.NpgsqlPasswordPacket()
29.11.2010 10:37:19 4412 Debug Entering NpgsqlPasswordPacket.WriteToStream()
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: NTLMSSP

?? 
(
.
29.11.2010 10:37:19 4412 Debug AuthenticationRequest message received from
server.
29.11.2010 10:37:19 4412 Debug Entering NpgsqlStartupState.Authenticate()
29.11.2010 10:37:19 4412 Debug Entering
NpgsqlPasswordPacket.NpgsqlPasswordPacket()
29.11.2010 10:37:19 4412 Debug Entering NpgsqlPasswordPacket.WriteToStream()
29.11.2010 10:37:19 4412 Debug Entering PGUtil.WriteString()
29.11.2010 10:37:19 4412 Debug String written: NTLMSSP    t   ? 
 H   `   f ? ?"
(
T E S T . X Y Z - D E r s c T R I D E N T ????J?#0
?n^
V?1d1m?5???7O+???? .
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: FATAL.
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: XX000.
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: could not accept SSPI security
context.
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: The logon attempt failed
(8009030c).
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: .\src\backend\libpq\auth.c.
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: 621.
29.11.2010 10:37:21 4412 Debug Entering PGUtil.ReadString()
29.11.2010 10:37:21 4412 Debug Get NpgsqlEventLog.LogLevel
29.11.2010 10:37:21 4412 Debug String read: pg_SSPI_error.
29.11.2010 10:37:21 4412 Debug ErrorResponse message from Server: could not
accept SSPI security context.
29.11.2010 10:37:21 4412 Normal An NpgsqlException occured: FATAL: XX000:
could not accept SSPI security context.

2010/11/23 Brar Piening <brar@gmx.de>

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?

2010/11/29 Reto Schöning <reto.schoening@gmail.com>

On Mon, 29 Nov 2010 15:27:35 +0100, Reto Sch�ning
<reto.schoening@gmail.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

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.schoening@gmail.com> wrote:

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@gmx.de>

-------- 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

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@gmx.de>

The issue has been addressed and patch has been submitted. Refer to Npgsql
mailing thread
http://lists.pgfoundry.org/pipermail/npgsql-devel/2011-February/001116.html
http://lists.pgfoundry.org/pipermail/npgsql-devel/2011-February/001116.html
.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/could-not-accept-SSPI-security-context-tp3275102p3367884.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Thank you very much for your patch!

I'm going to review and apply it.

As soon as it is done, I'll let you know.

On Wed, Feb 2, 2011 at 12:52, Ahmed <ahmed.shinwari@gmail.com> wrote:

The issue has been addressed and patch has been submitted. Refer to Npgsql
mailing thread
http://lists.pgfoundry.org/pipermail/npgsql-devel/2011-February/001116.html
http://lists.pgfoundry.org/pipermail/npgsql-devel/2011-February/001116.html
.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/could-not-accept-SSPI-security-context-tp3275102p3367884.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

Hi, Ahmed!

Thanks for checking this problem.

It is really a bug in Npgsql to convert the bytes value with ASCII encoder.

If we change that line to use the UTF-8 encoder, wouldn't it suffice
to fix this problem?

Also, wouldn't change the AuthenticationSSPI case to use context.Host
instead of Brar's code wouldn't break cases like the one he said in
his last email?

Thanks for feedback.

On Wed, Feb 2, 2011 at 14:11, Francisco Figueiredo Jr.
<francisco@npgsql.org> wrote:

Thank you very much for your patch!

I'm going to review and apply it.

As soon as it is done, I'll let you know.

On Wed, Feb 2, 2011 at 12:52, Ahmed <ahmed.shinwari@gmail.com> wrote:

The issue has been addressed and patch has been submitted. Refer to Npgsql
mailing thread
http://lists.pgfoundry.org/pipermail/npgsql-devel/2011-February/001116.html
http://lists.pgfoundry.org/pipermail/npgsql-devel/2011-February/001116.html
.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/could-not-accept-SSPI-security-context-tp3275102p3367884.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

--
Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

Hi Francisco,

I tried changing that one line to use UTF-8 encoder, but the password packet
didn't get fixed. It works smoothly if kept in byte array instead of string.

I think changing the AuthenticationSSPI case to use context.Host may break
the cases Brar's mentioned.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/could-not-accept-SSPI-security-context-tp3275102p3389684.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed
<ahmed.shinwari@gmail.com> wrote:

I tried changing that one line to use UTF-8 encoder, but the password packet
didn't get fixed. It works smoothly if kept in byte array instead of string.

Yes, as SSPI uses binary bytes we have to avoid to convert them to
characters and back to bytes during message generation.

While "char *buffer" in C can serve as both a string and a buffer of
binary bytes, we have "byte[]" as binary buffer and "string" as string
in c#.
This is the reason why we need to use byte[] in all places where libpq
uses char* without really caring whether there is a string inside or
some opaque bytes.

I think changing the AuthenticationSSPI case to use context.Host may break
the cases Brar's mentioned.

If this isn't necessary to fix the problem we should probably get some
more instight to what really happens here before fixing one end and
breaking the other.

Regards,

Brar

On Sat, Feb 19, 2011 at 11:31 PM, Brar Piening <brar@gmx.de> wrote:

On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed <ahmed.shinwari@gmail.com>
wrote:

I tried changing that one line to use UTF-8 encoder, but the password
packet
didn't get fixed. It works smoothly if kept in byte array instead of
string.

Yes, as SSPI uses binary bytes we have to avoid to convert them to
characters and back to bytes during message generation.

While "char *buffer" in C can serve as both a string and a buffer of binary
bytes, we have "byte[]" as binary buffer and "string" as string in c#.
This is the reason why we need to use byte[] in all places where libpq uses
char* without really caring whether there is a string inside or some opaque
bytes.

I think changing the AuthenticationSSPI case to use context.Host may break

the cases Brar's mentioned.

If this isn't necessary to fix the problem we should probably get some more
instight to what really happens here before fixing one end and breaking the
other.

I agree.

For now, Francisco may check in that part which fixes the bug due to
encoding. And, address the later issue after further investigation.

Hi Fransisco,

I tested the latest Npgsql driver (2.0.12.0), the issue has been fixed. I
was able to connect Npgsql test application from my Windows XP client
machine with the PostgreSQL server running on Windows 2003 Server.

Thank you for applying the patch.

On Thu, Feb 24, 2011 at 3:37 PM, Ahmed Shinwari <ahmed.shinwari@gmail.com>wrote: