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