GSSAPI authentication
Hello all We are running Postgres 14 on Ubuntu. Our Windows users connect passwordless using GSSAPI. This works great. Now we want users on Linux client to also connect passwordless using GSSAPI. Users on Linux log on using their Active Directory credentials, as the Linux host (Ubuntu 22.04) is joined to the domain. Logon to Linux works fine, access to Windows cifs shares works fine authentication with Kerberos. But psql won't connect using GSSAPI. It does hit the right pg_hba.conf line and the username is translated via pg_ident.conf, just fine. But psql says psql: error: connection to server at "srvpostgres4.xxx.local" (172.30.33.30), port 1609 failed: could not initiate GSSAPI security context: Unspecified GSS failure. Minor code may provide more information: Server not found in Kerberos database connection to server at "srvpostgres4.xxx.local" (172.30.33.30), port 1609 failed: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information: Server not found in Kerberos database Server log is like this 2022-06-06 08:14:01.176 CEST,"yyy","db1",474094,"172.30.32.213:33556",627e83c9.73bee,2,"authentication",2022-06-06 08:14:01 CEST,2/14544,0,FATAL,28000,"GSSAPI authentication failed for user ""yyy""","Connection matched pg_hba.conf line 15: ""hostall all 172.0.0.0/8 gss map=xxxlocal include_realm=0 krb_realm=""XXX.LOCAL""","client backend",,-3382135431624836920 We are a bit lost here. What are we missing? Regards Niels Jespersen
Re: GSSAPI authentication
This sounds like your PG service was unable to authenticate itself to AD. There's probably a trick to that somewhere - AD doesn't really want to be a Kerberos server, it just happens to use it 😉 On Mon, 6 June 2022, 10:05 pm Niels Jespersen, wrote: > Hello all > > > > We are running Postgres 14 on Ubuntu. Our Windows users connect > passwordless using GSSAPI. This works great. > > > > Now we want users on Linux client to also connect passwordless using > GSSAPI. Users on Linux log on using their Active Directory credentials, as > the Linux host (Ubuntu 22.04) is joined to the domain. Logon to Linux works > fine, access to Windows cifs shares works fine authentication with > Kerberos. > > > > But psql won't connect using GSSAPI. It does hit the right pg_hba.conf > line and the username is translated via pg_ident.conf, just fine. But psql > says > > > > psql: error: connection to server at "srvpostgres4.xxx.local" > (172.30.33.30), port 1609 failed: could not initiate GSSAPI security > context: Unspecified GSS failure. Minor code may provide more information: > Server not found in Kerberos database connection to server at > "srvpostgres4.xxx.local" (172.30.33.30), port 1609 failed: GSSAPI > continuation error: Unspecified GSS failure. Minor code may provide more > information: Server not found in Kerberos database > > > > Server log is like this > > > > 2022-06-06 08:14:01.176 > CEST,"yyy","db1",474094,"172.30.32.213:33556",627e83c9.73bee,2,"authentication",2022-06-06 > 08:14:01 CEST,2/14544,0,FATAL,28000,"GSSAPI authentication failed for user > ""yyy""","Connection matched pg_hba.conf line 15: ""hostall > all 172.0.0.0/8 gss map=xxxlocal include_realm=0 > krb_realm=""XXX.LOCAL""","client backend",,-3382135431624836920 > > > > We are a bit lost here. What are we missing? > > > > Regards Niels Jespersen > > > > > > > > > > > > > > > > > > >
Re: GSSAPI authentication
Looking closely at a configuration guide for MSSQL with Kerberos authentication, I see this part: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections?view=sql-server-ver16#Manual. It looks like it might be adapted to your question. --Michael On Mon, Jun 6, 2022 at 10:26 PM Michael van der Kolff < mvanderko...@gmail.com> wrote: > This sounds like your PG service was unable to authenticate itself to AD. > > There's probably a trick to that somewhere - AD doesn't really want to be > a Kerberos server, it just happens to use it 😉 > > On Mon, 6 June 2022, 10:05 pm Niels Jespersen, wrote: > >> Hello all >> >> >> >> We are running Postgres 14 on Ubuntu. Our Windows users connect >> passwordless using GSSAPI. This works great. >> >> >> >> Now we want users on Linux client to also connect passwordless using >> GSSAPI. Users on Linux log on using their Active Directory credentials, as >> the Linux host (Ubuntu 22.04) is joined to the domain. Logon to Linux works >> fine, access to Windows cifs shares works fine authentication with >> Kerberos. >> >> >> >> But psql won't connect using GSSAPI. It does hit the right pg_hba.conf >> line and the username is translated via pg_ident.conf, just fine. But psql >> says >> >> >> >> psql: error: connection to server at "srvpostgres4.xxx.local" >> (172.30.33.30), port 1609 failed: could not initiate GSSAPI security >> context: Unspecified GSS failure. Minor code may provide more information: >> Server not found in Kerberos database connection to server at >> "srvpostgres4.xxx.local" (172.30.33.30), port 1609 failed: GSSAPI >> continuation error: Unspecified GSS failure. Minor code may provide more >> information: Server not found in Kerberos database >> >> >> >> Server log is like this >> >> >> >> 2022-06-06 08:14:01.176 >> CEST,"yyy","db1",474094,"172.30.32.213:33556",627e83c9.73bee,2,"authentication",2022-06-06 >> 08:14:01 CEST,2/14544,0,FATAL,28000,"GSSAPI authentication failed for user >> ""yyy""","Connection matched pg_hba.conf line 15: ""hostall >> all 172.0.0.0/8 gss map=xxxlocal include_realm=0 >> krb_realm=""XXX.LOCAL""","client backend",,-3382135431624836920 >> >> >> >> We are a bit lost here. What are we missing? >> >> >> >> Regards Niels Jespersen >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
SV: GSSAPI authentication
Fra: Michael van der Kolff Sendt: 6. juni 2022 14:26 Til: Niels Jespersen Cc: pgsql-general list Emne: Re: GSSAPI authentication >This sounds like your PG service was unable to authenticate itself to AD. > >There's probably a trick to that somewhere - AD doesn't really want to be a >Kerberos server, it just happens to use it 😉 But it works fine when the same AD-user connects from Windows to the same postgres (Linux) server. Auth fails when the user initiates login from a Linux box (that otherwise uses Kerberized ressources just fine). Niels
Re: GSSAPI authentication
The part that you're missing, I think, is that Kerberized services require
a service account.
The SPN (service principal name) is the name that is used in Kerberos
contexts for that service account. PostgreSQL uses
postgres/${hostname}@${realm}
by default - see https://www.postgresql.org/docs/14/gssapi-auth.html.
The important part to note here is that $hostname must match what is
registered in the SPN for the user that you're using as the service account
in AD. It might (I don't know) have to match what AD believes about the
host from its PTR records for that domain as well.
--Michael
On Mon, Jun 6, 2022 at 11:33 PM Niels Jespersen wrote:
> *Fra:* Michael van der Kolff
> *Sendt:* 6. juni 2022 14:26
> *Til:* Niels Jespersen
> *Cc:* pgsql-general list
> *Emne:* Re: GSSAPI authentication
>
>
>
> >This sounds like your PG service was unable to authenticate itself to AD.
>
> >
>
> >There's probably a trick to that somewhere - AD doesn't really want to be
> a Kerberos server, it just happens to use it 😉
>
>
>
> But it works fine when the same AD-user connects from Windows to the same
> postgres (Linux) server. Auth fails when the user initiates login from a
> Linux box (that otherwise uses Kerberized ressources just fine).
>
>
>
> Niels
>
Re: GSSAPI authentication
Oh wait, I see.
On Mon, Jun 6, 2022 at 11:41 PM Michael van der Kolff <
mvanderko...@gmail.com> wrote:
> The part that you're missing, I think, is that Kerberized services require
> a service account.
>
> The SPN (service principal name) is the name that is used in Kerberos
> contexts for that service account. PostgreSQL uses
> postgres/${hostname}@${realm}
> by default - see https://www.postgresql.org/docs/14/gssapi-auth.html.
>
> The important part to note here is that $hostname must match what is
> registered in the SPN for the user that you're using as the service account
> in AD. It might (I don't know) have to match what AD believes about the
> host from its PTR records for that domain as well.
>
> --Michael
>
> On Mon, Jun 6, 2022 at 11:33 PM Niels Jespersen wrote:
>
>> *Fra:* Michael van der Kolff
>> *Sendt:* 6. juni 2022 14:26
>> *Til:* Niels Jespersen
>> *Cc:* pgsql-general list
>> *Emne:* Re: GSSAPI authentication
>>
>>
>>
>> >This sounds like your PG service was unable to authenticate itself to AD.
>>
>> >
>>
>> >There's probably a trick to that somewhere - AD doesn't really want to
>> be a Kerberos server, it just happens to use it 😉
>>
>>
>>
>> But it works fine when the same AD-user connects from Windows to the same
>> postgres (Linux) server. Auth fails when the user initiates login from a
>> Linux box (that otherwise uses Kerberized ressources just fine).
>>
>>
>>
>> Niels
>>
>
Re: GSSAPI authentication
>From the tiny bit I know about this, and a bit of googling, I arrived at
https://stackoverflow.com/questions/13850252/cannot-get-kerberos-service-ticket-krbexception-server-not-found-in-kerberos-d
.
It seems to suggest that either the KDC or your service account might have
bad PTR records, and you might want to capture DNS traffic on the two
hosts. Of course, I have no idea whether that is actually the issue.
I remember reading these docs ages ago - best of luck!
--Michael
On Mon, Jun 6, 2022 at 11:42 PM Michael van der Kolff <
mvanderko...@gmail.com> wrote:
> Oh wait, I see.
>
> On Mon, Jun 6, 2022 at 11:41 PM Michael van der Kolff <
> mvanderko...@gmail.com> wrote:
>
>> The part that you're missing, I think, is that Kerberized services
>> require a service account.
>>
>> The SPN (service principal name) is the name that is used in Kerberos
>> contexts for that service account. PostgreSQL uses
>> postgres/${hostname}@${realm}
>> by default - see https://www.postgresql.org/docs/14/gssapi-auth.html.
>>
>> The important part to note here is that $hostname must match what is
>> registered in the SPN for the user that you're using as the service account
>> in AD. It might (I don't know) have to match what AD believes about the
>> host from its PTR records for that domain as well.
>>
>> --Michael
>>
>> On Mon, Jun 6, 2022 at 11:33 PM Niels Jespersen wrote:
>>
>>> *Fra:* Michael van der Kolff
>>> *Sendt:* 6. juni 2022 14:26
>>> *Til:* Niels Jespersen
>>> *Cc:* pgsql-general list
>>> *Emne:* Re: GSSAPI authentication
>>>
>>>
>>>
>>> >This sounds like your PG service was unable to authenticate itself to
>>> AD.
>>>
>>> >
>>>
>>> >There's probably a trick to that somewhere - AD doesn't really want to
>>> be a Kerberos server, it just happens to use it 😉
>>>
>>>
>>>
>>> But it works fine when the same AD-user connects from Windows to the
>>> same postgres (Linux) server. Auth fails when the user initiates login from
>>> a Linux box (that otherwise uses Kerberized ressources just fine).
>>>
>>>
>>>
>>> Niels
>>>
>>
Re: [EXT] Re: Accessing composite type elements
> take a look at libpqtypes. it's client side extension library to libpq that > implements the binary protocol. > > https://github.com/pgagarinov/libpqtypes > > merlin Thx, Merlin… I’ll have a look see…
SV: GSSAPI authentication
Thank you for your suggestion. I arrived at the same suspicion. And that was
it. Reverse DNS was not set up correctly.
Fra: Michael van der Kolff
Sendt: 6. juni 2022 15:50
Til: Niels Jespersen
Cc: pgsql-general list
Emne: Re: GSSAPI authentication
From the tiny bit I know about this, and a bit of googling, I arrived at
https://stackoverflow.com/questions/13850252/cannot-get-kerberos-service-ticket-krbexception-server-not-found-in-kerberos-d.
It seems to suggest that either the KDC or your service account might have bad
PTR records, and you might want to capture DNS traffic on the two hosts. Of
course, I have no idea whether that is actually the issue.
I remember reading these docs ages ago - best of luck!
--Michael
On Mon, Jun 6, 2022 at 11:42 PM Michael van der Kolff
mailto:mvanderko...@gmail.com>> wrote:
Oh wait, I see.
On Mon, Jun 6, 2022 at 11:41 PM Michael van der Kolff
mailto:mvanderko...@gmail.com>> wrote:
The part that you're missing, I think, is that Kerberized services require a
service account.
The SPN (service principal name) is the name that is used in Kerberos contexts
for that service account. PostgreSQL uses postgres/${hostname}@${realm} by
default - see https://www.postgresql.org/docs/14/gssapi-auth.html.
The important part to note here is that $hostname must match what is registered
in the SPN for the user that you're using as the service account in AD. It
might (I don't know) have to match what AD believes about the host from its PTR
records for that domain as well.
--Michael
On Mon, Jun 6, 2022 at 11:33 PM Niels Jespersen
mailto:n...@dst.dk>> wrote:
Fra: Michael van der Kolff
mailto:mvanderko...@gmail.com>>
Sendt: 6. juni 2022 14:26
Til: Niels Jespersen mailto:n...@dst.dk>>
Cc: pgsql-general list
mailto:pgsql-general@lists.postgresql.org>>
Emne: Re: GSSAPI authentication
>This sounds like your PG service was unable to authenticate itself to AD.
>
>There's probably a trick to that somewhere - AD doesn't really want to be a
>Kerberos server, it just happens to use it 😉
But it works fine when the same AD-user connects from Windows to the same
postgres (Linux) server. Auth fails when the user initiates login from a Linux
box (that otherwise uses Kerberized ressources just fine).
Niels
