Re: unexpected failure for GSS Pg server

Matt Zagrabelny via Kerberos <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.general
Message-ID <CAOLfK3VPayYwxxDqQMH3urg3kL3=sKfsTkDkVphCJP9KDEq6=w@mail.gmail.com>
On Tue, Feb 8, 2022 at 11:54 AM Matt Zagrabelny <[email protected]> wrote:

> Greetings,
>
> I'm experiencing a failure between a GSS enabled Postgresql server and my
> CLI client.
>
> To my knowledge nothing has changed on the system to create this failure.
> I did modify some puppet configs, but according to the puppet log output
> (and stat'ing /etc/postgresql-common/krb5.keytab) file contents did not
> change.
>
> Here are the errors on on the Pg side:
>
> 2022-02-08 11:29:59.304 CST [19401] [unknown]@[unknown] FATAL:
>  unsupported frontend protocol 1234.5680: server supports 2.0 to 3.0
> 2022-02-08 11:29:59.315 CST [19402] mzagrabe@somedb FATAL:  accepting GSS
> security context failed
> 2022-02-08 11:29:59.315 CST [19402] mzagrabe@somedb DETAIL:  Unspecified
> GSS failure.  Minor code may provide more information: Request ticket
> server postgres/[email protected] kvno 3 not found in keytab;
> keytab is likely out of date
>
> NOTE: I still have some Pg servers where my GSS authentication is not
> failing. On those systems, Pg still logs the first line above: "unsupported
> frontend protocol 1234.5680: server supports 2.0 to 3.0". I only included
> it above for full disclosure.
>
> Here is the error on the client side:
>
> GSSAPI continuation error: Unspecified GSS failure.  Minor code may
> provide more information: Key version is not available
>
> Here is what klist has to say...
>
> Valid starting       Expires              Service principal
> 02/08/2022 11:10:57  02/08/2022 21:10:57  krbtgt/[email protected]
>         renew until 02/09/2022 11:10:46
> 02/08/2022 11:11:05  02/08/2022 21:10:57  postgres/
> [email protected]
>         renew until 02/09/2022 11:10:46
>
> Looking at the krb5kdc logs, I see no differences between successful GSS
> Pg auths and the failure mentioned above:
> Feb  8 11:36:42 auth krb5kdc[434]: TGS_REQ (8 etypes {18 17 20 19 16 23 25
> 26}) [IPV6 redacted]: ISSUE: authtime 1644340257, etypes {rep=18 tkt=18
> ses=18}, [email protected] for postgres/[email protected]
> Feb  8 11:36:42 auth krb5kdc[434]: closing down fd 14
> Feb  8 11:42:45 auth krb5kdc[434]: TGS_REQ (8 etypes {18 17 20 19 16 23 25
> 26}) [IPV6 redacted]: ISSUE: authtime 1644340257, etypes {rep=18 tkt=18
> ses=18}, [email protected] for postgres/
> [email protected]
> Feb  8 11:42:45 auth krb5kdc[434]: closing down fd 14
>
> Does anyone have any ideas of where to look to start to debug this issue?
>


After thinking a bit more on the problem. I believe the issue is that I
have different kvno (key version numbers).

For now (before anyone spends any time on my initial request for help) I
would say that I need to do more research and confirm that my process is
working as expected.

One request, where is the documentation that describes how/where the kvno
is used between the kdc and principals?

Thanks again!

-m
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.