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.com@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.COM@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.com@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}, mzagrabe@EXAMPLE.COM for postgres/db.example.com@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}, mzagrabe@EXAMPLE.COM for postgres/ successful.example.com@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?
On Tue, Feb 8, 2022 at 11:54 AM Matt Zagrabelny <mzagrabe@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.com@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.COM@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.com@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}, mzagrabe@EXAMPLE.COM for postgres/db.example.com@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}, mzagrabe@EXAMPLE.COM for postgres/ successful.example.com@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?
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><Dr. Dameon Wagner, Unix Platform Services
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Armed with that information, the most likely solution would be to
extract a fresh keytab (using either the kadmin "ktadd" subcommand, or
the handy `k5srvutil` command).
It may appear a bit old, but the O'Reilly book is still a classic
resource for becoming familiar with Kerberos and how it functions.
On Tue, Feb 8, 2022 at 5:03 PM Dameon Wagner <dameon.wagner@it.ox.ac.uk> wrote:
Armed with that information, the most likely solution would be to
extract a fresh keytab (using either the kadmin "ktadd" subcommand, or
the handy `k5srvutil` command).
Thanks for the detailed instructions, Dameon!
Do you know why performing the ktadd increases the kvno? I believe that is what tripped me up. I thought I was just "re-exporting" the key from the
KDC.
It may appear a bit old, but the O'Reilly book is still a classic
resource for becoming familiar with Kerberos and how it functions.
Ha! Yup! That book is in the office and I have been WFH for the last two years. :/
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><Dr. Dameon Wagner, Unix Platform Services
<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 42:37:35 |
Calls: | 6,648 |
Files: | 12,193 |
Messages: | 5,329,574 |