OK. I tried what you suggested. I pasted the whole sequence of commands and the results below. As you can see, the connection to postgres still failed, but it looks like it actually acquired the ticket (I think). What do you make of that?
Thanks again for the help.
Greig
[user@client ~]$ kdestroy
--------------------------------------------------------------------
[user@client ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_503)
Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
[user@client ~]$ kinit
Password for user@xxxxxxxxxx:
--------------------------------------------------------------------
[user@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: user@xxxxxxxxxx
Valid starting Expires Service principal
06/15/10 17:16:37 06/16/10 03:16:42 krbtgt/DOMAIN.COM@xxxxxxxxxx
renew until 06/16/10 03:16:37
Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
[user@client ~]$ psql -d postgres -h server.DOMAIN.COM
psql: FATAL: accepting GSS security context failed
DETAIL: Miscellaneous failure: Unknown code krb5 181
--------------------------------------------------------------------
[user@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: user@xxxxxxxxxx
Valid starting Expires Service principal
06/15/10 17:16:37 06/16/10 03:16:42 krbtgt/DOMAIN.COM@xxxxxxxxxx
renew until 06/16/10 03:16:37
06/15/10 17:17:01 06/16/10 03:16:42 POSTGRES/server.DOMAIN.COM@xxxxxxxxxx
renew until 06/16/10 03:16:37
Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
----- Original Message -----
From: "Stephen Frost" <sfrost@xxxxxxxxxxx>
To: greigwise@xxxxxxxxxxx
Cc: pgsql-general@xxxxxxxxxxxxxx, "Bryan Montgomery" <monty@xxxxxxxxxxx>
Sent: Tuesday, June 15, 2010 4:25:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: GSS Authentication
* greigwise@xxxxxxxxxxx (greigwise@xxxxxxxxxxx) wrote:
> kinit -S POSTGRES/host.domain.com user
>
> (where user is my account name in AD). That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket. Doing it this way though, the keytab file doesn't seem to come into play. Does this point to something in my keytab file being wrong?
Good that you were able to get a ticket manually. Next you need to try
getting a client application (eg: psql) to get that same ticket. Before
you run psql, do:
kdestroy
kinit
export PGKRBSRVNAME=POSTGRES
psql -d postgres -h host.domain.com
klist
And see if you acquired the same ticket you got with the manual klist.
> I did this:
>
> klist -ket postgres.keytab
>
> and got:
>
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 POSTGRES/host.domain.com@xxxxxxxxxx (DES cbc mode with RSA-MD5)
>
> That timestamp seems kinda funky, doesn't it? 12/31/69? That can't be right, can it?
The timestamp isn't really "right", but it shouldn't really hurt either-
that's just when it was "created". The encyprtion is crappy though and
might be disabled by default (MIT Kerberos recently started disabling
DES and lower encryption because it's horribly insecure). Check your
/etc/krb5.conf for permitted_enctypes. Also, after you get a
POSTGRES/host.domain.com ticket using kinit (or psql), do a klist -e and
see if the encryption type of the ticket you got matches that of the
keytab. If it doesn't, then you might have created multiple keys for
the same princ on the server (not generally a bad thing), but not
exported and loaded all of them into the keytab on the unix system
(which would be a problem...).
Thanks,
Stephen
Thanks again for the help.
Greig
[user@client ~]$ kdestroy
--------------------------------------------------------------------
[user@client ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_503)
Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
[user@client ~]$ kinit
Password for user@xxxxxxxxxx:
--------------------------------------------------------------------
[user@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: user@xxxxxxxxxx
Valid starting Expires Service principal
06/15/10 17:16:37 06/16/10 03:16:42 krbtgt/DOMAIN.COM@xxxxxxxxxx
renew until 06/16/10 03:16:37
Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
[user@client ~]$ psql -d postgres -h server.DOMAIN.COM
psql: FATAL: accepting GSS security context failed
DETAIL: Miscellaneous failure: Unknown code krb5 181
--------------------------------------------------------------------
[user@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: user@xxxxxxxxxx
Valid starting Expires Service principal
06/15/10 17:16:37 06/16/10 03:16:42 krbtgt/DOMAIN.COM@xxxxxxxxxx
renew until 06/16/10 03:16:37
06/15/10 17:17:01 06/16/10 03:16:42 POSTGRES/server.DOMAIN.COM@xxxxxxxxxx
renew until 06/16/10 03:16:37
Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
----- Original Message -----
From: "Stephen Frost" <sfrost@xxxxxxxxxxx>
To: greigwise@xxxxxxxxxxx
Cc: pgsql-general@xxxxxxxxxxxxxx, "Bryan Montgomery" <monty@xxxxxxxxxxx>
Sent: Tuesday, June 15, 2010 4:25:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: GSS Authentication
* greigwise@xxxxxxxxxxx (greigwise@xxxxxxxxxxx) wrote:
> kinit -S POSTGRES/host.domain.com user
>
> (where user is my account name in AD). That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket. Doing it this way though, the keytab file doesn't seem to come into play. Does this point to something in my keytab file being wrong?
Good that you were able to get a ticket manually. Next you need to try
getting a client application (eg: psql) to get that same ticket. Before
you run psql, do:
kdestroy
kinit
export PGKRBSRVNAME=POSTGRES
psql -d postgres -h host.domain.com
klist
And see if you acquired the same ticket you got with the manual klist.
> I did this:
>
> klist -ket postgres.keytab
>
> and got:
>
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 POSTGRES/host.domain.com@xxxxxxxxxx (DES cbc mode with RSA-MD5)
>
> That timestamp seems kinda funky, doesn't it? 12/31/69? That can't be right, can it?
The timestamp isn't really "right", but it shouldn't really hurt either-
that's just when it was "created". The encyprtion is crappy though and
might be disabled by default (MIT Kerberos recently started disabling
DES and lower encryption because it's horribly insecure). Check your
/etc/krb5.conf for permitted_enctypes. Also, after you get a
POSTGRES/host.domain.com ticket using kinit (or psql), do a klist -e and
see if the encryption type of the ticket you got matches that of the
keytab. If it doesn't, then you might have created multiple keys for
the same princ on the server (not generally a bad thing), but not
exported and loaded all of them into the keytab on the unix system
(which would be a problem...).
Thanks,
Stephen
Attachment:
signature.asc
Description: Digital signature
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
