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}(at)${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 <NJN(at)dst(dot)dk> wrote:

> *Fra:* Michael van der Kolff <mvanderkolff(at)gmail(dot)com>
> *Sendt:* 6. juni 2022 14:26
> *Til:* Niels Jespersen <NJN(at)dst(dot)dk>
> *Cc:* pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)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
>