Thread: "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/

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

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

thanks, and sorry for my slow responses, I'm bogged down by other stuff. I plan to get the source and try some things like

- force kerberos to see if the reason that NTLM is used is that kerberos fails and hope for some hints at the cause of the failure

- pass null instead of empty string for the principal

- check out the principal on the calling thread etc.

and post the results to the list. Could take I week or so until a get to that though.

Regards, Reto

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

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

 

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

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

That's great!

I'm glad to hear it.

Thank you very much for providing patches for this issue.

--
Sent from my Android phone

Francisco Figueiredo Jr.
Npgsql lead developer
fxjr.blogspot.com
twitter.com/franciscojunior

Ahmed wrote
>
> 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.
>
I've been trying to develop a new application in VB.NET (VS2008) against a
PostgreSQL 9.1.1 database server running on Windows Server 2008 using SSPI
authentication, and I'm running into this same error.  I've tried both
specifying the username and not specifying it in my
NpgsqlConnectionStringBuilder object, as well as trying to set or not set
the IntegratedSecurity property of the object (not setting it results in a
different error).  I was even looking for a property I could set to define
the user credentials (that's actually a whole different topic of discussion,
so we'll leave that alone for now).

I checked my version of Npgsql, and it's showing to be 2.0.11.0.  I tried
looking at the pgFoundry Web site and am unable to find a version 2.0.12.0
available.  Is this something that is still waiting for release, or am I
missing something?  If you require any additional details about this issue,
please let me know.

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

G_Hosa_Phat wrote:
> I've been trying to develop a new application in VB.NET (VS2008) against a
> PostgreSQL 9.1.1 database server running on Windows Server 2008 using SSPI
> authentication, and I'm running into this same error.  I've tried both
> specifying the username and not specifying it in my
> NpgsqlConnectionStringBuilder object, as well as trying to set or not set
> the IntegratedSecurity property of the object (not setting it results in a
> different error).  I was even looking for a property I could set to define
> the user credentials (that's actually a whole different topic of discussion,
> so we'll leave that alone for now).
>
> I checked my version of Npgsql, and it's showing to be 2.0.11.0.  I tried
> looking at the pgFoundry Web site and am unable to find a version 2.0.12.0
> available.  Is this something that is still waiting for release, or am I
> missing something?  If you require any additional details about this issue,
> please let me know.

Just a guess: You don't have something like "host all all 127.0.0.1/32
sspi" in your pg_hba.conf do you?

Regards,

Brar

Brar Piening wrote
>
> Just a guess: You don't have something like "host all all 127.0.0.1/32
> sspi" in your pg_hba.conf do you?
>
> Regards,
>
> Brar
>
I don't have that set.  Here's a sample from my pg_hba (slightly redacted to
obfuscate our internal network address scheme).

# TYPE    DATABASE    USER        CIDR-ADDRESS    METHOD
# ---------------------------------------------------------------------
#                        IPv4 LOCAL CONNECTIONS
# ---------------------------------------------------------------------
# Connections made from the server computer itself are only allowed if
# the user is a member of the Developers group, or a Super User.
# ---------------------------------------------------------------------
host    all        pgsuper        127.0.0.1/32    md5
host    all        +"ITDept"    127.0.0.1/32    sspi
host    all        all        127.0.0.1/32    reject
# ---------------------------------------------------------------------
#                       IPv4 INTRANET CONNECTIONS
# ---------------------------------------------------------------------
# If the IP address from which the request comes indicates that the
# user is on the Courtesy network and is physically located in one of
# our offices (Oklahoma City or Tulsa), use sspi authentication to
# validate the users credentials against Courtesy’s Active Directory.
# ---------------------------------------------------------------------
# Internal Network
# ---------------------------------------------------------------------
host    all                 pgsuper        172.16.10.0/24    md5
host    all                 +"Laptop"    172.16.10.50/32    ldap
ldapserver=ADSERVERNAME ldapprefix="MYDOMAIN\"
host    all                 +"ITDept"    172.16.10.0/24    sspi
host    appdb        +"Users"        172.16.10.0/24    sspi
# ---------------------------------------------------------------------
# Deny connection attempts from any source not explicitly identified
# in the rules above.
# ---------------------------------------------------------------------
host    all                 all        0.0.0.0/0        reject


# IPv6 local connections:
host    all        pgsuper        ::1/128        md5
host    all        +"ITDept"    ::1/128        sspi
host    all        all        ::1/128        reject

There are some specific requirements addressed in the configuration file,
and I'd love to ask some more questions about how to implement some of them,
but those aren't in the scope of this thread.  On this topic, however, this
configuratoin correctly uses the SSPI authentication when I try to connect
to the database through PGAdmin (I'm a member of the "ITDept" group), but
not when I'm testing my VB.NET application, it fails on the authentication
with the error from the thread title.

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

Ahmed wrote
>
> Hi,
>
> In my email, I mistakenly assumed that the next version would be 2.0.12.0,
> which was not. My bad.
>
> I checked the source and confirmed that the 2.0.11.0 has the bug, and the
> immediate next version (2.0.11.91) has the fix. You can use the version
> 2.0.11.92
> <http://pgfoundry.org/frs/?group_id=1000140&release_id=1889>,
> which is the latest stable release.
>
>
> -Ahmed
>
*@Ahmed -* Thank you so much.  I just ran a quick test and everything looks
like it's going to work great.  I was really going to have to start pulling
my hair out over that one if it didn't work.

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