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 <n...@dst.dk> wrote:
>
>> *Fra:* Michael van der Kolff <mvanderko...@gmail.com>
>> *Sendt:* 6. juni 2022 14:26
>> *Til:* Niels Jespersen <n...@dst.dk>
>> *Cc:* pgsql-general list <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
>>
>
