Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vOq0s-008y4H-0C for pgadmin-support@arkaria.postgresql.org; Fri, 28 Nov 2025 04:23:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vOq0q-0092iE-25 for pgadmin-support@arkaria.postgresql.org; Fri, 28 Nov 2025 04:23:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vOq0q-0092i6-0U for pgadmin-support@lists.postgresql.org; Fri, 28 Nov 2025 04:23:16 +0000 Received: from mail-yx1-xb12b.google.com ([2607:f8b0:4864:20::b12b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vOq0m-001qoL-1x for pgadmin-support@lists.postgresql.org; Fri, 28 Nov 2025 04:23:14 +0000 Received: by mail-yx1-xb12b.google.com with SMTP id 956f58d0204a3-640d43060d2so1137239d50.2 for ; Thu, 27 Nov 2025 20:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1764303791; x=1764908591; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2az0nG60Y97RQbVAgT+QLBSA4UDJYdPcdcyUuWb4oVw=; b=MY88U1EQTOuzHwx4k/na33d37UQZiG6PV+fq3q9L9rj8ouZkJw9gd5w8IeUDEhSxft CMIePgoTu4HRgi11nueFId5k/+2kE0+A+ilWwBUqsLHI6ltGTfR/XFq7h6vXTfWXltHj dvuwVZg+P6lfot3YIGyn/+x+ccr1CZZtw9b9YhCt5+U4GY6hvE93aTVu88i99AC1OMld mVmqq9Pj6+zfb3S6OPKJSNVNdV7zOyMrSQBnO7EtYCPUIEDInCwhhyakfyoqS50l7E5k qCLyDxh5Z9uET3QBAGCeYspcFdaNq10jeSTkTVlNXlPkq17PsD+RFUFqcXYik5rjguJ1 vf0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764303791; x=1764908591; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2az0nG60Y97RQbVAgT+QLBSA4UDJYdPcdcyUuWb4oVw=; b=VRCTB3w7IKk3HmtKU0puc2uMw4i1CRNItTneXirSK7sPmyRVKL6jmq0krcy0sdDTeQ Kk6TMNwyAxsRbhZBx3bPkMTjzLt+YmSL3WPO8nqV1Yxqj9HHOvnbI85MtvxDAx1LdHmJ cuhWWD57zREr/rWQGDKFzgagE7uLDfO8tzV+Hv2eHnRtqlWNh6dVf0ZqBzFCCHChwpXv WZMUF2YP35QHyzr6K8Jm7c6+olRajdOCOiLIQB/hypVkOHPLjoK+k35qAzdCKjpilNbY zPfObRB4HGXf8oiMmjscQd8UfNwCgBs3VAV6xWAyOOEo3RE0rz+ar+FAyKwoMUQIfoJi ZuvA== X-Gm-Message-State: AOJu0YznLPNUHp2SCDLLWu1q6zSIj0cFgqKZUgrGAcXaye0E+5v8uQ7F JWcPyRbj5vyFbpjUnaMO2mQk1DX1XmNHnU2Ad6XxmeuopmLc0AyFvo7M2mq1vreLo26KE3S8aYQ o8ig1py/x7ySz3pmEO1hhGoY8DP7QVjWe62LaS+b0 X-Gm-Gg: ASbGncttLEwZD8WaKTRpzeR+AnCzyeikjquNDxLHsNHTEt+p3SnOxxKKBkS2xw9w0TF 5y+kSSTIHTDv02RVM1IdKWrVRHOC4TK8wkD/UsbNS823bvr5ko7k5AcdWRryy4GjlGLNeS+TzPW fB5GF3SSzYoxNDwBTNZ1cPEWarky8RgK1Bk9eqku351XotpdD/LUWEcxbMn8YXQM5Mf2Y+Qv778 qDQ+NGleRijz/dSYWfw0+aqnM0JvTmFWzKmXs13xntSBPeJn4FxMq5x2+EPt6q5PTevNMPvuw== X-Google-Smtp-Source: AGHT+IH//LioLH2RTHWCWs04IlbXZaqEaWlNOjfY30eQUGNMcKLBRKw1hJHCpi4Qn8qPs5mwrBBGo4FvsRlH+Lg0FAo= X-Received: by 2002:a53:acd4:0:10b0:63e:1c4c:302b with SMTP id 956f58d0204a3-64302ab979bmr16172990d50.47.1764303791038; Thu, 27 Nov 2025 20:23:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Khushboo Vashi Date: Fri, 28 Nov 2025 09:52:59 +0530 X-Gm-Features: AWmQ_bkpuD0sELmcr7Q5qZxCoMpasaJ9y7TJe21qzprLKQ58cYmlOKjEkWS9H-0 Message-ID: Subject: Re: Kerberos authentication in pgAdmin4 server To: Haiko Sawatzky Cc: pgadmin-support@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000bdb1a006449ffc1d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bdb1a006449ffc1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 27, 2025 at 8:02=E2=80=AFPM Haiko Sawatzky 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 prove= n > 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 > pgadmin_cache_testuser@AD.DOMAIN.LAB > 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%3DY7GRWVd= 2WF_e4xbOM%2BxzO1W_A%40mail.gmail.com > ). > > Just for some additional information, I have Postgres configured with "gs= s > include_realm=3D0 krb_realm=3DAD.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=E2=80=AFAM Khushboo Vashi < > khushboo.vashi@enterprisedb.com> wrote: > >> Hi, >> >> While creating the server, have you checked the `Kerberos authentication >> ?' field? >> >> On Wed, Nov 26, 2025 at 8:57=E2=80=AFPM Haiko Sawatzky >> wrote: >> >>> Hello. >>> >>> I've been having seemingly the same issue as in the following thread: >>> https://www.postgresql.org/message-id/flat/CAFOhELe6QLp1ZJevkupqE9np%3D= Y7GRWVd2WF_e4xbOM%2BxzO1W_A%40mail.gmail.com#0e78a396033b6d4d5922b1fa9b4ee8= 80 >>> I would like to see if someone can help me diagnose what I'm doing wron= g. >>> >>> 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 mo= ment >>> I try to connect to the Postgresql server: >>> pgadmin-1 | Error: connection failed: connection to server at >>> "", port 5432 failed: GSSAPI continuation error: No credent= ials >>> 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 >>> pgadmin_cache_testuser@AD.DOMAIN.LAB >>> >>> 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 >>> "", port 5432 failed: connection to server at "= ", >>> 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 t= o >>> set an environment variable for "KRB_KTNAME" or set "KRB_KTNAME" in the >>> pgAdmin config, and that this should work instead of needing to configu= re >>> "default_keytab_name" in krb5.conf. But this has not worked for me at a= ll, >>> I can't go without explicitly creating a krb5.conf file that specifies >>> "default_keytab_name =3D /path/to/keytab". But as I said, when I config= ure >>> this in krb5.conf, the login into pgAdmin using Kerberos works. >>> >> --000000000000bdb1a006449ffc1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, Nov 27, = 2025 at 8:02=E2=80=AFPM Haiko Sawatzky <haikosaw69@gmail.com> wrote:
Hello Khushboo.

<= /div>
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 t= hat the ticket that=C2=A0the pgAdmin container creates for my=C2=A0user is = correct, by logging into the Postgres server using psql:
<= font face=3D"arial, sans-serif">I can log into pgAdmin successfully via Fir= efox on Windows. The pgAdmin container will then have a ticket for my user = in=C2=A0/var/lib/pgadmin/krbccache/. I can exec into the running pgAdmin co= ntainer, and use the generated ticket to log into the Postgresql server usi= ng psql:
faaa414c9552:/pgadmin4$ = ls -la /var/lib/pgadmin/krbccache/
total 16
drwxr-xr-x =C2=A0 =C2=A02= pgadmin =C2=A0root =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04096 Nov 27 11:02 .drwxrwxr-x =C2=A0 =C2=A06 pgadmin =C2=A0root =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A04096 Nov 27 11:03 ..
-rw------- =C2=A0 =C2=A01 pgadmin =C2=A0root = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03104 Nov 27 09:52 pgadmin_cache_testuser@= AD.DOMAIN.LAB
faaa414c9552:/pgadmin4# /usr/local/pgsql-17/psql --host te= st-postgres1.ad.domain.lab --dbname postgres --username testuser --command = "values(session_user);"
=C2=A0column1
---------
=C2=A0te= stuser
(1 row)

Then I did another test=C2=A0(I=C2=A0mentioned doing=C2=A0= this test in my last message, but it turns out yesterday I had broken my SP= N,=C2=A0so that's why it wasn't working yesterday).

The default credential cache name is determi= ned by the following, in descending order of priority:
  • The KRB5C= CNAME environment variable.
  • The default_ccache_name profile variabl= e in [libdefaults].
  • The hardcoded default, DEFCCNAME.

= pgAdmin uses the first one, so it gets priority. Somehow, on your system, t= he 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_505= 0 explains that it gets the second priority (default_ccache_name).

C= an you conduct further investigation on your system to determine why the en= vironment variable is not working?

Thanks,
Khushboo

I= copied=C2=A0my user ti= cket from=C2=A0/var/lib= /pgadmin/krbccache/ to=C2=A0/tmp/krb5cc_5050, and then I could successfully= connect to my postgres server from within=C2=A0pgAdmin (in my Firefox brow= ser).
So to me, it looks like the li= bpq library is not checking for the correct ticket path, sort of like I und= erstand the last message in the thread I mentioned in my last message (https:= //www.postgresql.org/message-id/CAFOhELe6QLp1ZJevkupqE9np%3DY7GRWVd2WF_e4xb= OM%2BxzO1W_A%40mail.gmail.com).

Just= for some additional information, I have Postgres configured with "gss= include_realm=3D0 krb_realm=3DAD.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=E2=80=AFAM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:
Hi,

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

=
On Wed, No= v 26, 2025 at 8:57=E2=80=AFPM Haiko Sawatzky <haikosaw69@gmail.com> wrote:
Hello.

I've=C2=A0been having= seemingly the same issue as in the following thread: https://www.postgresql.org/message-id/flat/CAFOhELe6QLp1ZJevkupqE9n= p%3DY7GRWVd2WF_e4xbOM%2BxzO1W_A%40mail.gmail.com#0e78a396033b6d4d5922b1fa9b= 4ee880
I would like to see if someone can help me diagnose what I= 9;m doing wrong.

=
My environment is:
=C2=A0 * pgAdmin4 server version 9.10, r= unning in a Docker container (dpage/pgadmin4:9.10) - Ubuntu=C2=A0server=C2=A0VM
=C2=A0 * Post= gresql server configured for Kerberos authentication=C2=A0- Ubuntu server V= M
=C2=A0 * Our company is using M= icrosoft Windows Active Directory

What I have working:
=C2= =A0 * Logging into Postgresql directly with my Microsoft Active Directory u= ser using Kerberos (from Windows & Linux)
=C2=A0 *=C2=A0Logging into pgAdmin web with my Microsoft Act= ive Directory user using Kerberos (currently only on Firefox on Windows)
What's=C2=A0currently not working for me is the Kerberos authentic= ation from within pgAdmin to the Postgresql server. The container logs this= the moment I try to connect to the Postgresql server:
pgadmin-1 =C2=A0|= Error: connection failed: connection to server at "<ip-address>= ", port 5432 failed: GSSAPI continuation error: No credentials were su= pplied, or the credentials were unavailable or inaccessible: No Kerberos cr= edentials available (default cache: FILE:/tmp/krb5cc_5050)

I do howe= ver 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/krbcc= ache/'
total 12
drwxr-xr-x =C2=A0 =C2=A02 pgadmin =C2=A0root =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04096 Nov 26 09:42 .
drwxrwxr-x =C2=A0 =C2= =A06 pgadmin =C2=A0root =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04096 Nov 26 09:42= ..
-rw------- =C2=A0 =C2=A01 pgadmin =C2=A0root =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A01533 Nov 26 09:42 pgadmin_cache_testuser@AD.DOMAIN.LAB

= I've=C2=A0tried, just to see if it would do a login:
<= font face=3D"monospace">=C2=A0 * Create an environment variable for the who= le container KRB5CCNAME as the absolute pa= th to my Kerberos ticket in krbccache
=C2=A0 *=C2=A0copy the ticket in /var/lib/pgadmin/krbccache/ to= /tmp/krb5cc_5050
The environment= variable had no affect, but copying the ticket to=C2=A0/tmp/krb5cc_5050 ch= anged the=C2=A0error that I got to:
pgadmin-1 =C2=A0| Error: connection failed: connection to server at &quo= t;<ip-address>", port 5432 failed: connection to server at "= ;<ip-address>", port 5432 failed: GSSAPI continuation error: Uns= pecified GSS failure.=C2=A0 Minor code may provide more information: The ti= cket isn't for us

Another issue I've=C2=A0already= worked around: the documentation specifies to set an environment variable = for "KRB_KTNAME"=C2=A0or set "KRB_KTNAME" in the pgAdmi= n config,=C2=A0and that this should work instead of needing to configure &q= uot;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 sp= ecifies "default_keytab_name =3D /path/to/keytab". But as I said,= when I configure this in krb5.conf, the login into pgAdmin using Kerberos = works.
--000000000000bdb1a006449ffc1d--