Re: "could not accept SSPI security context"

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

On Sat, Jan 21, 2012 at 7:31 AM, G_Hosa_Phat [via PostgreSQL] <
ml-node+s1045698n5162113h57(at)n5(dot)nabble(dot)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
> # ---------------------------------------------------------------------
> 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.
>
> ------------------------------
> 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<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3275102&code=YWhtZWQuc2hpbndhcmlAZ21haWwuY29tfDMyNzUxMDJ8NzYyNDkyNzEx>
> .
> NAML<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>