Subject: Kerberos authentication in pgAdmin4 server

From: Haiko Sawatzky <[email-masked]>
Date: Wed, 26 Nov 2025 11:45:36 -0300

Hello.

I've been having seemingly the same issue as in the following thread:
https://www.postgresql.org/message-id/flat/CAFOhELe6QLp1ZJevkupqE9np%3DY7GRWVd2WF_e4xbOM%2BxzO1W_A%40mail.gmail.com#0e78a396033b6d4d5922b1fa9b4ee880
I would like to see if someone can help me diagnose what I'm doing wrong.

My environment is:
  * pgAdmin4 server version 9.10, running in a Docker container
(dpage/pgadmin4:9.10) - Ubuntu server VM
  * Postgresql server configured for Kerberos authentication - Ubuntu
server VM
  * Our company is using Microsoft Windows Active Directory

What I have working:
  * Logging into Postgresql directly with my Microsoft Active Directory
user using Kerberos (from Windows & Linux)
  * Logging into pgAdmin web with my Microsoft Active Directory user using
Kerberos (currently only on Firefox on Windows)

What's currently not working for me is the Kerberos authentication from
within pgAdmin to the Postgresql server. The container logs this the moment
I try to connect to the Postgresql server:
pgadmin-1  | Error: connection failed: connection to server at
"<ip-address>", port 5432 failed: GSSAPI continuation error: No credentials
were supplied, or the credentials were unavailable or inaccessible: No
Kerberos credentials available (default cache: FILE:/tmp/krb5cc_5050)

I do however find a ticket for my Kerberos session in the cache directory:
docker exec -ti pgadmin-test-pgadmin-1 bash -c 'ls -la
/var/lib/pgadmin/krbccache/'
total 12
drwxr-xr-x    2 pgadmin  root          4096 Nov 26 09:42 .
drwxrwxr-x    6 pgadmin  root          4096 Nov 26 09:42 ..
-rw-------    1 pgadmin  root          1533 Nov 26 09:42
[email-masked]

I've tried, just to see if it would do a login:
  * Create an environment variable for the whole container KRB5CCNAME as
the absolute path to my Kerberos ticket in krbccache
  * copy the ticket in /var/lib/pgadmin/krbccache/ to /tmp/krb5cc_5050
The environment variable had no affect, but copying the ticket
to /tmp/krb5cc_5050 changed the error that I got to:
pgadmin-1  | Error: connection failed: connection to server at
"<ip-address>", port 5432 failed: connection to server at "<ip-address>",
port 5432 failed: GSSAPI continuation error: Unspecified GSS failure.
Minor code may provide more information: The ticket isn't for us

Another issue I've already worked around: the documentation specifies to
set an environment variable for "KRB_KTNAME" or set "KRB_KTNAME" in the
pgAdmin config, and that this should work instead of needing to configure
"default_keytab_name" in krb5.conf. But this has not worked for me at all,
I can't go without explicitly creating a krb5.conf file that specifies
"default_keytab_name = /path/to/keytab". But as I said, when I configure
this in krb5.conf, the login into pgAdmin using Kerberos works.

---

From: Khushboo Vashi <[email-masked]>
Date: Thu, 27 Nov 2025 10:52:16 +0530

Hi,

While creating the server, have you checked the `Kerberos authentication ?'
field?

---

From: Haiko Sawatzky <[email-masked]>
Date: Thu, 27 Nov 2025 11:31:56 -0300

Hello Khushboo.

Yes I have enabled the kerberos auth switch in the postgres connection.

I've also done some more troubleshooting, and in my opinion, I have proven
that the ticket that the pgAdmin container creates for my user is correct,
by logging into the Postgres server using psql:
I can log into pgAdmin successfully via Firefox on Windows. The pgAdmin
container will then have a ticket for my user
in /var/lib/pgadmin/krbccache/. I can exec into the running pgAdmin
container, and use the generated ticket to log into the Postgresql server
using psql:
faaa414c9552:/pgadmin4$ ls -la /var/lib/pgadmin/krbccache/
total 16
drwxr-xr-x    2 pgadmin  root          4096 Nov 27 11:02 .
drwxrwxr-x    6 pgadmin  root          4096 Nov 27 11:03 ..
-rw-------    1 pgadmin  root          3104 Nov 27 09:52
[email-masked]
faaa414c9552:/pgadmin4# /usr/local/pgsql-17/psql --host
test-postgres1.ad.domain.lab --dbname postgres --username testuser
--command "values(session_user);"
 column1
---------
 testuser
(1 row)

Then I did another test (I mentioned doing this test in my last message,
but it turns out yesterday I had broken my SPN, so that's why it wasn't
working yesterday).
I copied my user ticket from /var/lib/pgadmin/krbccache/
to /tmp/krb5cc_5050, and then I could successfully connect to my postgres
server from within pgAdmin (in my Firefox browser).
So to me, it looks like the libpq library is not checking for the correct
ticket path, sort of like I understand the last message in the thread I
mentioned in my last message (
https://www.postgresql.org/message-id/CAFOhELe6QLp1ZJevkupqE9np%3DY7GRWVd2WF_e4xbOM%2BxzO1W_A%40mail.gmail.com
).

Just for some additional information, I have Postgres configured with "gss
include_realm=0 krb_realm=AD.DOMAIN.LAB" in the hba file, and in my
connection I specify the fqdn for the Postgres host, my username without
the realm, and switch on kerberos authentication.

On Thu, Nov 27, 2025 at 2:22 AM Khushboo Vashi <
[email-masked]> wrote:

> Hi,
>
> While creating the server, have you checked the `Kerberos authentication
> ?' field?
>
>>   * Logging into pgAdmin web with my Microsoft Active Directory user
>> using Kerberos (currently only on Firefox on Windows)
>>

---

From: Khushboo Vashi <[email-masked]>
Date: Fri, 28 Nov 2025 09:52:59 +0530

Hi,

> but it turns out yesterday I had broken my SPN, so that's why it wasn't

The default credential cache name is determined by the following, in
descending order of priority:

   - The KRB5CCNAME environment variable.
   - The default_ccache_name profile variable in [libdefaults].
   - The hardcoded default, DEFCCNAME.

pgAdmin uses the first one, so it gets priority. Somehow, on your system,
the env variable is not readable or reachable, even though you tried to set
it explicitly, and it didn't work. Copying the ticket to /tmp/krbcc_5050
explains that it gets the second priority (default_ccache_name).

Can you conduct further investigation on your system to determine why the
environment variable is not working?

Thanks,
Khushboo

>>>   * Create an environment variable for the whole container KRB5CCNAME
>>> as the absolute path to my Kerberos ticket in krbccache

---

From: Haiko Sawatzky <[email-masked]>
Date: Fri, 28 Nov 2025 10:56:20 -0300

In an attempt to get more information on what is happening, I have added a
few logger lines in the python source code and built a docker image.
In web\pgadmin\utils\locker.py, after line #34 I added these two (35 & 44):
#34  current_app.logger.info("Acquired a lock.")
*#35  current_app.logger.info <http://current_app.logger.info>("The
locker.KRB5CCNAME value is '{krb_val}'".format(krb_val =
session['KRB5CCNAME']))*
...
#42  else:
#43      environ.pop('KRB5CCNAME', None)
*#44  current_app.logger.info <http://current_app.logger.info>("The locker
environ['KRB5CCNAME'] value is '{krb_val}'".format(krb_val =
environ['KRB5CCNAME']))*

Here's a log snippet of a login attempt using my customized pgAdmin image:
2025-11-28 10:21:57,912: INFO   pgadmin:        Connection Request for
server#1
2025-11-28 10:21:57,915: INFO   pgadmin:        Waiting for a lock.
2025-11-28 10:21:57,915: INFO   pgadmin:        Acquired a lock.
2025-11-28 10:21:57,915: INFO   pgadmin:        The locker.KRB5CCNAME value
is 'FILE:/var/lib/pgadmin/krbccache/[email-masked]'
2025-11-28 10:21:57,915: INFO   pgadmin:        The locker
environ['KRB5CCNAME'] value is
'FILE:/var/lib/pgadmin/krbccache/[email-masked]'
2025-11-28 10:21:57,922: INFO   pgadmin:        Released a lock.
2025-11-28 10:21:57,923: INFO   pgadmin:        Failed to connect to the
database server(#1) for connection (DB:postgres) with error message as
below:connection failed: connection to server at "<ip-address>", port 5432
failed: GSSAPI continuation error: No credentials were supplied, or the
credentials were unavailable or inaccessible: No Kerberos credentials
available (default cache: FILE:/tmp/krb5cc_5050)
2025-11-28 10:21:57,923: ERROR  pgadmin:        Could not connect to
server(#1) - 'test-postgres1'.
Error: connection failed: connection to server at "<ip-address>", port 5432
failed: GSSAPI continuation error: No credentials were supplied, or the
credentials were unavailable or inaccessible: No Kerberos credentials
available (default cache: FILE:/tmp/krb5cc_5050)

When I try setting this exact value in krb5.conf, I can log in to the
Postgres server with the kerberos ticket:
[libdefaults]
    default_ccache_name
= FILE:/var/lib/pgadmin/krbccache/[email-masked]
...

I'm guessing that in other environments, the cached ticket path also
includes the '@REALM', and that the '@' will get escapted down the line
when an attempt is made to access the file?
Do you have any other clues of what to look for or what I can try? Any way
I can log what's happening while the connection is attempted?

On Fri, Nov 28, 2025 at 1:23 AM Khushboo Vashi <
[email-masked]> wrote:

>> I've also done some more troubleshooting, and in my opinion, I have
>> proven that the ticket that the pgAdmin container creates for my user is
>> correct, by logging into the Postgres server using psql:
>> So to me, it looks like the libpq library is not checking for the
>> correct ticket path, sort of like I understand the last message in the
>> thread I mentioned in my last message (
>> Just for some additional information, I have Postgres configured with
>> "gss include_realm=0 krb_realm=AD.DOMAIN.LAB" in the hba file, and in my
>>>> Another issue I've already worked around: the documentation specifies
>>>> to set an environment variable for "KRB_KTNAME" or set "KRB_KTNAME" in the