Re: Kerberos Authentication to Postgres from PGADMIN in IPA REALM

Hi,

On Wed, Apr 12, 2023 at 1:59 PM Gregory McKaige <gmckaige(at)gmail(dot)com> wrote:

> 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
>
So, the cache file is created.

> /var/lib/pgadmin/krbccache #
>
>
>
>
>
> I'm not sure why PGAdmin is looking for this info @/tmp/krb5cc_5050?
>
pgAdmin isn't looking for @/tmp/krb5cc_5050. pgAdmin sets the
environment KRB5CCNAME
variable to the pgadmin_cache_a01-6(at)MY(dot)LAB file path and libpq will access
that file through the env variable. If this file is not authenticated then
libpq/Postgres will check for the default cache @/tmp/krb5cc_5050.

We have reproduced this issue at our end and will fix it. Please log this
issue @ https://github.com/pgadmin-org/pgadmin4/issues.

Thanks,
Khushboo

>
>
> [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
>>>>>>
>>>>>>