On Fri, Aug 3, 2012 at 4:41 PM, Stephen Frost <sfrost@snowman.net> wrote:
> John,
>
> * John Slattery (johntslattery@gmail.com) wrote:
>> Following is the information you suggested reporting. The test is with
>> 'User Name' = 'john'. I used a system DSN generated with the ODBC data
>> source administrator. Before I set 'User Name' = 'john', I
>> successfully tested the DSN with user csmprovver whose AD and PG names
>> are identical with 'User Name' = ''.
>
> After you have tried to connect, you might try running 'klist' on the
> Windows system and reviewing the tickets to see if you acquired a ticket
> for the postgres service.
>
> In general, this does look very similar to our setup (which works just
> fine). I will say that we always use "include_realm=1" and then have
> the mapping include the realm, eg:
>
> pg_hba.conf:
>
> host all all 0.0.0.0/0 gss include_realm=1 map=krbmap
>
> pg_ident.conf:
>
> krbmap /^[mM]12345@REALM\.ORG$ sfrost
>
> In the end, however, it sounds like that's some kind of GSSAPI issue
> that's causing trouble (hence the gssapi auth complaint in the server
> log). Is there any additional information around that error about what
> the GSSAPI error is? Have you tried increasing the verbosity of the
> server messages to see if more information is provided?
>
> Thanks,
>
> Stephen
Stephen,
I noticed a configuration option in postgresql.conf to increase the
message level to the client. I set client_min_messages = debug5 and
generated the attached mylog files.
mylog_1812.log is for an unsuccessful attempt to authenticate with
'User Name' = 'john'. This line from the log seems to suggest that
psqlODBC is not using the correct SPN:
[3876-0.060]!!! inlen=0 svcprinc=postgres/postgresql.columbia-stmarys.org
It should be 'POSTGRESQL/postgresql.columbia-stmarys.org. An
examination of tickets on the client with klist shows that a ticket is
not present for POSTGRESQL.
The attempt fails with:
[3876-0.060](-2146893053)The specified target is unknown or
unreachable in DoKerberosEtcProcessAuthentication:PerformKerberosEtcClientHandshake
ERRNO=1
mylog_936.log is for an unsuccessful attempt to authenticate with
'User Name' = 'jslatter'. Predictably, it fails with:
[2608-0.120]CONN ERROR: func=LIBPQ_connect, desc='', errnum=101,
errmsg='FATAL: role "jslatter" does not exist
but doesn't complain about a target being unreachable. An examination
of tickets on the client shows that one for
POSTGRESQL/postgresql.columbia-stmarys.org is now present.
Though you've already indicated it's not possible, the only thing that
occurs to me is that in the special case where 'User Name' is
specified, psqlODBC may not be respecting the PGKRBSRVNAME environment
variable.
John