Обсуждение: Kerberos Authentication to Postgres from PGADMIN in IPA REALM
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.1VM - Rocky Linux 9.1 as Docker Host-- PGADMIN (Container) 6.15VM - Rocky Linux 9.1 providing Postgres 15From 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.I configured the delegation (First time in the Linux world I've done this so maybe it's wrong?) using:ipa servicedelegationtarget-addipa servicedelegationtarget-ad-memberipa servicedelegationrule-addipa servicedelegationrule-add-memberipa servicedelegationrule-add-targetThen rebooted everything, but same results. Is there a way in the PGAdmin container to turn up logging to see what's happening?Thanks,Greg
Вложения
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,KhushbooOn 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.1VM - Rocky Linux 9.1 as Docker Host-- PGADMIN (Container) 6.15VM - Rocky Linux 9.1 providing Postgres 15From 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.I configured the delegation (First time in the Linux world I've done this so maybe it's wrong?) using:ipa servicedelegationtarget-addipa servicedelegationtarget-ad-memberipa servicedelegationrule-addipa servicedelegationrule-add-memberipa servicedelegationrule-add-targetThen rebooted everything, but same results. Is there a way in the PGAdmin container to turn up logging to see what's happening?Thanks,Greg
Вложения
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,KhushbooOn 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.1VM - Rocky Linux 9.1 as Docker Host-- PGADMIN (Container) 6.15VM - Rocky Linux 9.1 providing Postgres 15From 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.I configured the delegation (First time in the Linux world I've done this so maybe it's wrong?) using:ipa servicedelegationtarget-addipa servicedelegationtarget-ad-memberipa servicedelegationrule-addipa servicedelegationrule-add-memberipa servicedelegationrule-add-targetThen rebooted everything, but same results. Is there a way in the PGAdmin container to turn up logging to see what's happening?Thanks,Greg
Вложения
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,KhushbooOn 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.1VM - Rocky Linux 9.1 as Docker Host-- PGADMIN (Container) 6.15VM - Rocky Linux 9.1 providing Postgres 15From 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.I configured the delegation (First time in the Linux world I've done this so maybe it's wrong?) using:ipa servicedelegationtarget-addipa servicedelegationtarget-ad-memberipa servicedelegationrule-addipa servicedelegationrule-add-memberipa servicedelegationrule-add-targetThen rebooted everything, but same results. Is there a way in the PGAdmin container to turn up logging to see what's happening?Thanks,Greg
Вложения
Hi,
On Wed, Apr 12, 2023 at 1:59 PM Gregory McKaige <gmckaige@gmail.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@MY.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@MY.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
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,KhushbooOn 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.1VM - Rocky Linux 9.1 as Docker Host-- PGADMIN (Container) 6.15VM - Rocky Linux 9.1 providing Postgres 15From 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.I configured the delegation (First time in the Linux world I've done this so maybe it's wrong?) using:ipa servicedelegationtarget-addipa servicedelegationtarget-ad-memberipa servicedelegationrule-addipa servicedelegationrule-add-memberipa servicedelegationrule-add-targetThen rebooted everything, but same results. Is there a way in the PGAdmin container to turn up logging to see what's happening?Thanks,Greg
