Re: Kerberos Authentication to Postgres from PGADMIN in IPA REALM

From config_local.py on the container I see:

 

  KERBEROS_CCACHE_DIR = os.path.join(DATA_DIR, 'krbccache')                

 

Elsewhere in the config_local.py on the container I see DATA_DIR defined as:

    if SERVER_MODE:                                                        

        DATA_DIR = '/var/lib/pgadmin'

 

It seems like the cache is where the config_local.py and config.py are pointing?

/var/lib/pgadmin # ls -lah

total 172K  

drwxrwxr-x    6 pgadmin  root         101 Apr 12 08:12 .

drwxr-xr-x    1 root     root          48 Oct 17 10:42 ..

drwxr-xr-x    2 pgadmin  root           6 Apr 11 11:41 azurecredentialcache

drwxr-xr-x    2 pgadmin  root          40 Apr 11 11:44 krbccache

-rw-------    1 pgadmin  root      168.0K Apr 12 08:12 pgadmin4.db

drwx------    2 pgadmin  root        4.0K Apr 12 07:42 sessions

drwxr-xr-x    3 pgadmin  root          26 Apr 11 11:44 storage

/var/lib/pgadmin # cd krbccache/

/var/lib/pgadmin/krbccache # ls

pgadmin_cache_a01-6@MY.LAB

/var/lib/pgadmin/krbccache #

 

 

 I'm not sure why PGAdmin is looking for this info @/tmp/krb5cc_5050?

 

 

 Or maybe I'm misunderstanding how this works.

On Tue, Apr 11, 2023 at 5:10 PM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

After looking at the credential cache error in your logs, it looks like while connecting, Postgres is considering the default_cache_name (/tmp/krb5cc_5050) setting which you must have configured in the krb5.conf file.

pgAdmin sets the KRB5CCNAME environment variable to the absolute path of the credential cache. The credential cache is stored by pgAdmin upon login. Users can set the path by setting the KERBEROS_CCACHE_DIR in the config.py file. So, while connecting to Postgresql, it should consider KRB5CCNAME value which is not happening here. You can check whether the credential cache file is generated or not at the location set to the KERBEROS_CCACHE_DIR.

On Tue, Apr 11, 2023 at 3:15 PM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Apr 11, 2023 at 2:50 PM Gregory McKaige <gmckaige@gmail.com> wrote:

Let me know if I should reply-all or just back to the list (I haven't used a mailing list before).

Yes. you should reply-all. 

Yes, I have the Kerberos Authentication toggle button "enabled".

Can you confirm whether your credential cache file exists or not (/tmp/krb5cc_5050) while you are trying to connect the server?  

On Tue, Apr 11, 2023 at 3:21 PM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

As you can log in to the pgAdmin web app through Kerberos, you should be able to connect Postgres through Kerberos.

One thing I want to confirm is that when you created the server, you turned on the Kerberos authentication option. 

See the below screen-shot.

Thanks,

Khushboo

On Tue, Apr 11, 2023 at 1:17 PM Gregory McKaige <gmckaige@gmail.com> wrote:

Environment:

  VM -  FreeIPA providing LDAP/Kerberos (FreeIPA 4.10.0) on Rocky Linux 9.1

  VM - Rocky Linux 9.1 as Docker Host

         -- PGADMIN (Container) 6.15

  VM - Rocky Linux 9.1 providing Postgres 15

From an IPA joined client Kerberos SSO works to the PGAdmin container (no extra login prompt)

From an IPA joined client with psql installed I can connect to Postgres using Kerberos. I see the  "GSSAPI - Encrypted connection" in the connection.

When I attempt to connect with the same account from the PGAdmin web application I receive the following error in the web interface.

"GSSAPI continuation error. No credentials were supplied, or the credentials were unavailable or inaccessible. No Kerberos credentials available.(Default cache: FILE:/tmp/krb5cc_5050)

On Postgres I checked the logs and it looks like the right user is being sent....but not authenticated:

2023-04-11 13:31:53.364 +07 [3858] FATAL:  GSSAPI authentication failed for user "a01-6"
2023-04-11 13:31:53.364 +07 [3858] DETAIL:  Connection matched pg_hba.conf line 91: "host    all             all             192.168.1.0/24            gss include_realm=0 krb_realm=MY.LAB"

Initially I thought it might be the typical kerberos double-hop issue with Kerberos delegation and I found the following article on Kerberos delelgation.

https://access.redhat.com/documentation/en%02us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/assembly_using-constrained-delegation-in-idm_configuring-and-managing-idm#con_constrained-delegation-in-identity-management_assembly_using-constrained-delegation-in-idm

I configured the delegation (First time in the Linux world I've done this so maybe it's wrong?) using:

ipa servicedelegationtarget-add

ipa servicedelegationtarget-ad-member

ipa servicedelegationrule-add

ipa servicedelegationrule-add-member

ipa servicedelegationrule-add-target

Then rebooted everything, but same results. Is there a way in the PGAdmin container to turn up logging to see what's happening?

Thanks,

Greg