Обсуждение: GSSAPI / Kerberos Authentication
I am currently trying to configure a Centos6.x – postgresql-9.3 server to authenticate using gssapi. I have several servers I have already configured and are working (a combination of Oracle Linux and Centos, all 6.x series with 9.2,3 or 4). Our company use vas for an interface to Kerberos, The errors I am getting are as follows:
[sweingar@pglgisprtd001 ~]$ psql -hpglgisprtd001 -dpostgres
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information
GSSAPI continuation error: Server not found in Kerberos database
or from a windows client
C:\Users\sweingar>psql -hpglgisprtd001.sempra.com -Usweingar
psql: SSPI continuation error: The specified target is unknown or unreachable
(80090303)
I see nothing worthwhile in the postgresql log, nor in /var/log/messages. I have verified the dns record to my kdc works (or at least I can ping), I am sort of at a loss of where to look next.
I am currently trying to configure a Centos6.x – postgresql-9.3 server to authenticate using gssapi. I have several servers I have already configured and are working (a combination of Oracle Linux and Centos, all 6.x series with 9.2,3 or 4). Our company use vas for an interface to Kerberos, The errors I am getting are as follows:
[sweingar@pglgisprtd001 ~]$ psql -hpglgisprtd001 -dpostgres
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information
GSSAPI continuation error: Server not found in Kerberos database
or from a windows client
C:\Users\sweingar>psql -hpglgisprtd001.sempra.com -Usweingar
psql: SSPI continuation error: The specified target is unknown or unreachable
(80090303)
I see nothing worthwhile in the postgresql log, nor in /var/log/messages. I have verified the dns record to my kdc works (or at least I can ping), I am sort of at a loss of where to look next.
The spn is POSTGRES/pglgisprtd001.sempra.com@CORP.SE.SEMPRA.COM, as I set up different servers, the server in the spn changes of course. The server name resolves, and if I do a klist on the keytab the realm matches.
I am thinking that it has to do with our “vas” & “vasd” systems and how it is configured. But I can’t really say.
From: Bear Giles [mailto:bgiles@coyotesong.com]
Sent: Thursday, June 2, 2016 3:44 PM
To: Weingartner, Steven <SWeingartner@semprautilities.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] GSSAPI / Kerberos Authentication
I was just looking at the Kerberos support. Is your server principal postgres/x.y.z@REALM, where x.y.z is the DNS name for your server? It probably won't affect you but think it needs to be POSTGRES/x.y.z@REALM for windows networks.
I'll have to check my notes for more details, e.g., I'm 99% sure it's 'postgres' and not 'postgresql'.
I know you need to use password authentication from the client - and the username has to be simple (bob@REALM, not bob/postgres@REALM). I'll be submitting a patch to support a keytab file and compound principals when I have some free time.
Bear
On Thu, Jun 2, 2016 at 4:23 PM, Weingartner, Steven <SWeingartner@semprautilities.com> wrote:
I am currently trying to configure a Centos6.x – postgresql-9.3 server to authenticate using gssapi. I have several servers I have already configured and are working (a combination of Oracle Linux and Centos, all 6.x series with 9.2,3 or 4). Our company use vas for an interface to Kerberos, The errors I am getting are as follows:
[sweingar@pglgisprtd001 ~]$ psql -hpglgisprtd001 -dpostgres
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information
GSSAPI continuation error: Server not found in Kerberos database
or from a windows client
C:\Users\sweingar>psql -hpglgisprtd001.sempra.com -Usweingar
psql: SSPI continuation error: The specified target is unknown or unreachable
(80090303)
I see nothing worthwhile in the postgresql log, nor in /var/log/messages. I have verified the dns record to my kdc works (or at least I can ping), I am sort of at a loss of where to look next.
This email originated outside of Sempra Energy. Be cautious of attachments, web links, or requests for information.
The spn is POSTGRES/pglgisprtd001.sempra.com@CORP.SE.SEMPRA.COM, as I set up different servers, the server in the spn changes of course. The server name resolves, and if I do a klist on the keytab the realm matches.
I am thinking that it has to do with our “vas” & “vasd” systems and how it is configured. But I can’t really say.
From: Bear Giles [mailto:bgiles@coyotesong.com]
Sent: Thursday, June 2, 2016 3:44 PM
To: Weingartner, Steven <SWeingartner@semprautilities.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] GSSAPI / Kerberos Authentication
I was just looking at the Kerberos support. Is your server principal postgres/x.y.z@REALM, where x.y.z is the DNS name for your server? It probably won't affect you but think it needs to be POSTGRES/x.y.z@REALM for windows networks.
I'll have to check my notes for more details, e.g., I'm 99% sure it's 'postgres' and not 'postgresql'.
I know you need to use password authentication from the client - and the username has to be simple (bob@REALM, not bob/postgres@REALM). I'll be submitting a patch to support a keytab file and compound principals when I have some free time.
Bear
On Thu, Jun 2, 2016 at 4:23 PM, Weingartner, Steven <SWeingartner@semprautilities.com> wrote:
I am currently trying to configure a Centos6.x – postgresql-9.3 server to authenticate using gssapi. I have several servers I have already configured and are working (a combination of Oracle Linux and Centos, all 6.x series with 9.2,3 or 4). Our company use vas for an interface to Kerberos, The errors I am getting are as follows:
[sweingar@pglgisprtd001 ~]$ psql -hpglgisprtd001 -dpostgres
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information
GSSAPI continuation error: Server not found in Kerberos database
or from a windows client
C:\Users\sweingar>psql -hpglgisprtd001.sempra.com -Usweingar
psql: SSPI continuation error: The specified target is unknown or unreachable
(80090303)
I see nothing worthwhile in the postgresql log, nor in /var/log/messages. I have verified the dns record to my kdc works (or at least I can ping), I am sort of at a loss of where to look next.
This email originated outside of Sempra Energy. Be cautious of attachments, web links, or requests for information.
All, * Bear Giles (bgiles@coyotesong.com) wrote: > I remember reading comments in the code that case matters - postgres and > POSTGRES are not the same - but I'm drawing a blank on the rest. I just > started looking at the code myself though - others probably have more > experience. That's correct, case absolutely matters and it needs to match. There are options in postgresql.conf to control what's expected. This is a source of common issue when coming from Windows clients to Linux servers (or the other way around). In particular, review section 19.3.3 of the 9.5 docs: https://www.postgresql.org/docs/9.5/static/auth-methods.html#GSSAPI-AUTH For the client side, review krbsrvname: https://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS Check the klist from the client side and also look at the keytab that's on the server and what's in the KDC database and make sure they all match. What the client asks for from the KDC needs to be what the KDC has and what is installed in the keytab on the server for it all to work. Thanks! Stephen
Вложения
All,
* Bear Giles (bgiles@coyotesong.com) wrote:
> I remember reading comments in the code that case matters - postgres and
> POSTGRES are not the same - but I'm drawing a blank on the rest. I just
> started looking at the code myself though - others probably have more
> experience.
That's correct, case absolutely matters and it needs to match.
There are options in postgresql.conf to control what's expected. This
is a source of common issue when coming from Windows clients to Linux
servers (or the other way around).
In particular, review section 19.3.3 of the 9.5 docs:
https://www.postgresql.org/docs/9.5/static/auth-methods.html#GSSAPI-AUTH
For the client side, review krbsrvname:
https://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
Check the klist from the client side and also look at the keytab that's
on the server and what's in the KDC database and make sure they all
match. What the client asks for from the KDC needs to be what the KDC
has and what is installed in the keytab on the server for it all to
work.
Thanks!
Stephen
Bear, * Bear Giles (bgiles@coyotesong.com) wrote: > The problem is connecting to the server using the JDBC driver. It currently > uses the connection username and password to log into the KDC and also > provides the username to the database. That works fine with a simple > username but gets confused with principal names like above. What I plan to > add is the ability to specify a keytab instead of the username and password > for the JDBC driver. I banged my head against the wall for awhile before > downloading the code and single-stepping through the login process. :-) Doesn't the JDBC driver have a way to use an existing credential cache though..? Generally speaking, one uses something like k5start to initialize (and keep current) a credential cache by using a keytab and then the daemon (or what-have-you) uses that. The JDBC driver really shouldn't be accepting the username/password at all.. Thanks! Stephen