Hi, On Thu, Nov 27, 2025 at 8:02 PM Haiko Sawatzky <[email protected]> wrote:
> 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 protected] > 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). > 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 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 protected]> wrote: > >> Hi, >> >> While creating the server, have you checked the `Kerberos authentication >> ?' field? >> >> On Wed, Nov 26, 2025 at 8:57 PM Haiko Sawatzky <[email protected]> >> wrote: >> >>> 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 protected] >>> >>> 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. >>> >>
