Re: GSSAPI authentication

Oh wait, I see.

On Mon, Jun 6, 2022 at 11:41 PM Michael van der Kolff <
mvanderkolff(at)gmail(dot)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}(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
>>
>