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 1vQ7Ed-00Arr9-0Y for pgadmin-support@arkaria.postgresql.org; Mon, 01 Dec 2025 16:58:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQ7Eb-003gRF-2F for pgadmin-support@arkaria.postgresql.org; Mon, 01 Dec 2025 16:58:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vOyxg-00Bddn-2W for pgadmin-support@lists.postgresql.org; Fri, 28 Nov 2025 13:56:37 +0000 Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vOyxe-001zs7-1o for pgadmin-support@lists.postgresql.org; Fri, 28 Nov 2025 13:56:36 +0000 Received: by mail-io1-xd29.google.com with SMTP id ca18e2360f4ac-949031532f9so92045239f.0 for ; Fri, 28 Nov 2025 05:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764338192; x=1764942992; 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=YCNFw0iYyefCJ8zApn2D46EBS9/HGwGVovQ/EzVm4xc=; b=GdHSQtYYMlarkn+kS0CvEpVWjU5amtayD0b8L9Xh0OBRRBB8GSlfGv2H3C0kcV4meB YWJkBQnvACqdc4P+pmYXxvSrTvZxhLyMzZMe4ZLvIRBnJ6yEJuQ+XyANAPwstLPrkApt 8xc6Ec/P46bPz+ncRGv9dPLdpEKYZFH8kKTQxfHSaeCC79eNNy8yYbalNp8l8g98al65 T9UD0pYBpuM+9P5fQPe2P4XLa9tuH9QwP3Ja8WbXYz4ujo7Vo8j+BfvAKdj0ew1MVKXD UbNQL5vg+jEpkX5cr9H6e4b8aTFLgxEG0Xg2KAMD9BGGfVG+QwFJYA5eFeLw6r4IYD4U nygA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764338192; x=1764942992; 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=YCNFw0iYyefCJ8zApn2D46EBS9/HGwGVovQ/EzVm4xc=; b=hpR2catpY+7gbhnFhRNKZeGUJ0Nokp0GTCnM+SH+o0BJ/J3R3i4G3anjrwZAaNSDjH 7AtQf+4Q/K7Ej8Vnq071CH4z+Cn7CIFrv5M+qLXI0bv/WmLcIRjy1yh7nEKJHt6KrL1i otWuZlhJnD4x8AVsGMeNWk3r6WIpI05XxwtyYUpfN3+H+G8RyeyBBU1kCPG7P6QbpJ5y qpaZ1R08zc6NIrCIebZihjps9TvWOnSYiUViJ9aVi8sOJxZZGjJzi9Jm3W1lJb8WZmMl d9w67OGDpQKAoM9zkSlQH0xnCEdOdnTUtF9oHQwUKfzt6MXvIIVpiBKuBn/glz3E4Iez bNBQ== X-Gm-Message-State: AOJu0Yz64eEofCWAFhmLUvhxHqVwj21//VKMa5O5YJ7kCgWYizZurSFA ttaCSO3CsE2J/8gmtKNFepcJgSIe8LCEIz1xe1dMoltPpVsHU7aeNmx4y4xXUCYXEo8k7DnFFHG P917NXinEt2ZPIGmD2xODgcv3SpKwN0E= X-Gm-Gg: ASbGncsOghmELlDQkgrKV5gmuNvmHmHFAyJgY6q0+9vUr7rAmT4XqVnw2XcXkdVpwJs Gpx3iYpZt5Bd7napug97zUD82NR/d8C+jAJKesagqNr3og3VI9iLO4U3j+74PMbEsByfknpNSHx WpXn+wfPI/R+Kxb8OJD6VLcN1QIXrNDPxZWg8tklnRyIsXpaK2NjMfdEIf3+rH38i1eCdL5+Fz7 K0n/zyVTuSAE3w9et7+NMJjViiW8lL+b2eWvIzsdAK5HEluTkSlgRTSAoIHhFB4pgDV5/Md X-Google-Smtp-Source: AGHT+IHmLfk3AhcN1VyXjA/2yii+nxPYJxNUTt9y9SHCVcMXEjKnrvAi2nqmUxpqpV3HlVHwtYEQ4/FQ+aLR6y0ibkE= X-Received: by 2002:a6b:6302:0:b0:949:55d:4a41 with SMTP id ca18e2360f4ac-94939ed1d4emr2186304839f.7.1764338191804; Fri, 28 Nov 2025 05:56:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Haiko Sawatzky Date: Fri, 28 Nov 2025 10:56:20 -0300 X-Gm-Features: AWmQ_bksfzcBmhxa73sFPAdUokLZG2zaeONPrjpwhbFMj5oYxcSdzd_p9NP2OOw Message-ID: Subject: Re: Kerberos authentication in pgAdmin4 server To: Khushboo Vashi Cc: pgadmin-support@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000002fac650644a7ffcb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002fac650644a7ffcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ("The locker.KRB5CCNAME value is '{krb_val}'".format(krb_val =3D session['KRB5CCNAME']))* ... #42 else: #43 environ.pop('KRB5CCNAME', None) *#44 current_app.logger.info ("The locker environ['KRB5CCNAME'] value is '{krb_val}'".format(krb_val =3D 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/pgadmin_cache_testuser@AD.DOMAIN.LAB' 2025-11-28 10:21:57,915: INFO pgadmin: The locker environ['KRB5CCNAME'] value is 'FILE:/var/lib/pgadmin/krbccache/pgadmin_cache_testuser@AD.DOMAIN.LAB' 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 "", 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 "", 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 =3D FILE:/var/lib/pgadmin/krbccache/pgadmin_cache_testuser@AD.DOMAIN.LAB ... 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=E2=80=AFAM Khushboo Vashi < khushboo.vashi@enterprisedb.com> wrote: > 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 >> 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 serve= r >> 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 s= et > 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 postgre= s >> 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%3DY7GRWV= d2WF_e4xbOM%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 i= n 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 authenticatio= n >>> ?' 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%3= DY7GRWVd2WF_e4xbOM%2BxzO1W_A%40mail.gmail.com#0e78a396033b6d4d5922b1fa9b4ee= 880 >>>> 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 Director= y >>>> 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 fro= m >>>> within pgAdmin to the Postgresql server. The container logs this the m= oment >>>> I try to connect to the Postgresql server: >>>> pgadmin-1 | Error: connection failed: connection to server at >>>> "", port 5432 failed: GSSAPI continuation error: No creden= tials >>>> 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 >>>> 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 config= ure >>>> "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 =3D /path/to/keytab". But as I said, when I confi= gure >>>> this in krb5.conf, the login into pgAdmin using Kerberos works. >>>> >>> --0000000000002fac650644a7ffcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 doc= ker image.
In=C2=A0web\pgadmin\utils\locker.py, after line #34 I added = these two (35 & 44):
#34=C2=A0 current_app.logger.info("Acq= uired a lock.")
#35=C2=A0= current_app.logger.info(&qu= ot;The locker.KRB5CCNAME value is '{krb_val}'".format(krb_val = =3D session['KRB5CCNAME']))
...
#42=C2=A0 else:
#43= =C2=A0 =C2=A0 =C2=A0 environ.pop('KRB5CCNAME', None)
#44=C2=A0=C2=A0current_app.logger.info("The locker environ['KRB= 5CCNAME'] value is '{krb_val}'".format(krb_val =3D environ= ['KRB5CCNAME']))

Here's a l= og snippet of a login attempt using my customized pgAdmin image:
2025-11-28 10:21:57,912: INFO =C2=A0 pgadmin: =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection Request for server#1
2025-11-28 10:21:57,915= : INFO =C2=A0 pgadmin: =C2=A0 =C2=A0 =C2=A0 =C2=A0Waiting for a lock.
20= 25-11-28 10:21:57,915: INFO =C2=A0 pgadmin: =C2=A0 =C2=A0 =C2=A0 =C2=A0Acqu= ired a lock.
2025-11-28 10:21:57,915: INFO =C2=A0 pgadmin: =C2=A0 =C2=A0= =C2=A0 =C2=A0The locker.KRB5CCNAME value is 'FILE:/var/lib/pgadmin/krb= ccache/pgadmin_cache_testuser@AD.DOMAIN.LAB'
2025-11-28 10:21:57,915= : INFO =C2=A0 pgadmin: =C2=A0 =C2=A0 =C2=A0 =C2=A0The locker environ['K= RB5CCNAME'] value is 'FILE:/var/lib/pgadmin/krbccache/pgadmin_cache= _testuser@AD.DOMAIN.LAB'
2025-11-28 10:21:57,922: INFO =C2=A0 pgadmi= n: =C2=A0 =C2=A0 =C2=A0 =C2=A0Released a lock.
2025-11-28 10:21:57,923: = INFO =C2=A0 pgadmin: =C2=A0 =C2=A0 =C2=A0 =C2=A0Failed to connect to the da= tabase 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 credential= s available (default cache: FILE:/tmp/krb5cc_5050)
2025-11-28 10:21:57,9= 23: ERROR =C2=A0pgadmin: =C2=A0 =C2=A0 =C2=A0 =C2=A0Could not connect to se= rver(#1) - 'test-postgres1'.
Error: connection failed: connectio= n to server at "<ip-address>", port 5432 failed: GSSAPI con= tinuation error: No credentials were supplied, or the credentials were unav= ailable or inaccessible: No Kerberos credentials available (default cache: = FILE:/tmp/krb5cc_5050)

When I try setting this exact = value in krb5.conf,=C2=A0I can log in to the Postgres server with the kerbe= ros ticket:
[libdefaults]<= /div>
=C2=A0 =C2=A0 default_ccache_name =3D=C2= =A0FILE:/var/lib/pgadmin/krbccache/pgadmin_cache_testuser@AD.DOMAIN.LAB
...

I'm guessing that in other environments, the cached ticket pa= th also includes the '@REALM', and that the '@' will get es= capted=C2=A0down 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=E2= =80=AFAM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:
Hi,
On = Thu, Nov 27, 2025 at 8:02=E2=80=AFPM Haiko Sawatzky <haikosaw69@gmail.com> wrote:<= br>
Hello Khushboo.

Y= es 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=C2=A0the pgAdmin contain= er creates for my=C2=A0user is correct, by logging into the Postgres server= using psql:
I can log in= to pgAdmin successfully via Firefox on Windows. The pgAdmin container will = then have a ticket for my user in=C2=A0/var/lib/pgadmin/krbccache/. I can e= xec 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 =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=A0ro= ot =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 2= 7 09:52 pgadmin_cache_testuser@AD.DOMAIN.LAB
faaa414c9552:/pgadmin4# /us= r/local/pgsql-17/psql --host test-postgres1.ad.domain.lab --dbname postgres= --username testuser --command "values(session_user);"
=C2=A0c= olumn1
---------
=C2=A0testuser
(1 row)

Then= I did another test=C2=A0(I=C2=A0mentioned doing=C2=A0this test in my last message, but it turns o= ut yesterday I had broken my SPN,=C2=A0so that's why it wasn't work= ing yesterday).

The default c= redential cache name is determined by the following, in descending order of= priority:
  • The KRB5CCNAME environment variable.
  • The defa= ult_ccache_name profile variable in [libdefaults].
  • The hardcoded de= fault, DEFCCNAME.

pgAdmin uses the first one, so it gets prior= ity. 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. Copyi= ng 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=C2=A0= my user ticket from=C2= =A0/var/lib/pgadmin/krb= ccache/ to=C2=A0/tmp/krb5cc_5050, and then I could successfully connect to = my postgres server from within=C2=A0pgAdmin (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.post= gresql.org/message-id/CAFOhELe6QLp1ZJevkupqE9np%3DY7GRWVd2WF_e4xbOM%2BxzO1W= _A%40mail.gmail.com).

Just for some = additional information, I have Postgres configured with "gss include_r= ealm=3D0 krb_realm=3DAD.DOMAIN.LAB" in the hba file, and in my connect= ion 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> wr= ote:
Hi,

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

On Wed, Nov 26, 20= 25 at 8:57=E2=80=AFPM Haiko Sawatzky <haikosaw69@gmail.com> wrote:

<= /div>
My environment is:=C2=A0 * pgAdmin4 server version 9.10, running i= n a Docker container (dpage/pgadmin4:9.10) - Ubuntu=C2=A0server=C2=A0VM
=C2=A0 * Postgresql s= erver configured for Kerberos authentication=C2=A0- Ubuntu server VM=
=C2=A0 * Our company is using Microsoft= Windows Active Directory

What I have working:
=C2=A0 * Lo= gging into Postgresql directly with my Microsoft Active Directory user usin= g Kerberos (from Windows & Linux)
=C2=A0 *=C2=A0Logging into pgAdmin web with my Microsoft Active Direct= ory user using Kerberos (currently only on Firefox on Windows)

What&= #39;s=C2=A0currently not working for me is the Kerberos authentication from= within pgAdmin to the Postgresql server. The container logs this the momen= t I try to connect to the Postgresql server:
pgadmin-1 =C2=A0| Error: co= nnection failed: connection to server at "<ip-address>", po= rt 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 =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 pgadmi= n =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=A0= 1533 Nov 26 09:42 pgadmin_cache_testuser@AD.DOMAIN.LAB

I've=C2= =A0tried, just to see if it would do a login:
=C2=A0 * Create an environment variable for the whole contai= ner KRB5CCNAME as the absolute path to my = Kerberos ticket in krbccache
=C2=A0 *=C2=A0copy the ticket in /var/lib/pgadmin/krbccache/ to /tmp/krb= 5cc_5050
The environment variable= had no affect, but copying the ticket to=C2=A0/tmp/krb5cc_5050 changed the= =C2=A0error that I got to:
pgadmi= n-1 =C2=A0| Error: connection failed: connection to server at "<ip-= address>", port 5432 failed: connection to server at "<ip-a= ddress>", port 5432 failed: GSSAPI continuation error: Unspecified = GSS failure.=C2=A0 Minor code may provide more information: The ticket isn&= #39;t for us

Another issue I've=C2=A0already worked a= round: the documentation specifies to set an environment variable for "= ;KRB_KTNAME"=C2=A0or set "KRB_KTNAME" in the pgAdmin config,= =C2=A0and that this should work instead of needing to configure "defau= lt_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 &= quot;default_keytab_name =3D /path/to/keytab". But as I said, when I c= onfigure this in krb5.conf, the login into pgAdmin using Kerberos works.
--0000000000002fac650644a7ffcb--