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(at)MY(dot)LAB

/var/lib/pgadmin/krbccache #

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

[image: image.png]

Or maybe I'm misunderstanding how this works.

On Tue, Apr 11, 2023 at 5:10 PM Khushboo Vashi <
khushboo(dot)vashi(at)enterprisedb(dot)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(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> On Tue, Apr 11, 2023 at 2:50 PM Gregory McKaige <gmckaige(at)gmail(dot)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".
>>> [image: image.png]
>>>
>>>
>>> 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(dot)vashi(at)enterprisedb(dot)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.
>>>>
>>>> [image: Screenshot 2023-04-11 at 1.48.38 PM.png]
>>>>
>>>> Thanks,
>>>> Khushboo
>>>>
>>>> On Tue, Apr 11, 2023 at 1:17 PM Gregory McKaige <gmckaige(at)gmail(dot)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
>>>>>
>>>>>