* greigwise@comcast.net (greigwise@comcast.net) 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
nowklist shows that I have a ticket. Doing it this way though, the keytab file doesn't seem to come into play. Does
thispoint 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@DOMAIN.COM (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
