Re: [GENERAL] "could not accept SSPI security context"

[Ahmed Shinwari]

On Sat, Feb 19, 2011 at 11:31 PM, Brar Piening  wrote:

> On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed 
> 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.



>
> Regards,
>
> Brar
>

Re: [GENERAL] "could not accept SSPI security context"

[Ahmed Shinwari]

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

>
>
> On Sat, Feb 19, 2011 at 11:31 PM, Brar Piening  wrote:
>
>> On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed 
>> 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.
>
>
>
>>
>> Regards,
>>
>> Brar
>>
>
>

Re: [GENERAL] "could not accept SSPI security context"

[Ahmed Shinwari]

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 ,
which is the latest stable release.


-Ahmed


On Sat, Jan 21, 2012 at 7:31 AM, G_Hosa_Phat [via PostgreSQL] <
ml-node+s1045698n5162113...@n5.nabble.com> wrote:

>  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
> # -
> hostall pgsuper 172.16.10.0/24 md5
> hostall +"Laptop" 172.16.10.50/32 ldap
> ldapserver=ADSERVERNAME ldapprefix="MYDOMAIN\"
> hostall +"ITDept" 172.16.10.0/24 sspi
> hostappdb +"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.
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://postgresql.1045698.n5.nabble.com/could-not-accept-SSPI-security-context-tp3275102p5162113.html
>  To unsubscribe from "could not accept SSPI security context", click 
> here
> .
> NAML
>