On Tue, Feb 8, 2022 at 11:54 AM Matt Zagrabelny <mzagr...@d.umn.edu> 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/db.example....@example.com 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/example....@example.com
> renew until 02/09/2022 11:10:46
> 02/08/2022 11:11:05 02/08/2022 21:10:57 postgres/
> db.example....@example.com
> 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}, mzagr...@example.com for postgres/db.example....@example.com
> 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}, mzagr...@example.com for postgres/
> successful.example....@example.com
> 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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
