From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Kerberos support broken on MSVC builds for Windows x64? |
Date: | 2020-09-02 18:08:38 |
Message-ID: | 20200902180838.GE29590@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Dave Page (dpage(at)pgadmin(dot)org) wrote:
> On Wed, Sep 2, 2020 at 9:05 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >> Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
> >> used under Windows.
>
> Here's a patch to make it build successfully (against head). I believe the
> changes to Solution.pm should be back patched all the way, and the rest to
> 12.
Looks about right.. I might pull out the code from both places that are
setting that variable into a dedicated function to be used from both
though.
> Testing however, has been more problematic - I suspect at least partly
> because of my Kerberos newbie-ness. I have a test server in an Ubuntu VM,
> which I've used quite successfully to authenticate against another VM
> running PG 12 on Ubuntu, from both Ubuntu and Windows clients. Using that,
> but with a Windows client running MIT Kerberos I find that getting a ticket
> takes a good 30 seconds or so. Postgres also seems to get it's ticket
> successfully via the keytab file:
So, from Windows clients that don't have MIT KfW installed, you're able
to authenticate against PG 12 on Ubuntu using Kerberos, right..? With
PG built using SSPI on the client side, I'm guessing?
Kerberos uses reverse DNS to try to check what hostname to use when
requesting a ticket, I wonder if what you're seeing here is a delay due
to there not being reverse DNS functional in the environment, perhaps..?
> C:\pg>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
> Ticket cache: API:Initial default ccache
> Default principal: dpage(at)PGADMIN(dot)ORG
>
> Valid starting Expires Service principal
> 09/02/20 15:06:49 09/03/20 01:06:49 krbtgt/PGADMIN(dot)ORG(at)PGADMIN(dot)ORG
> renew until 09/03/20 15:06:31
> 09/02/20 15:07:06 09/03/20 01:06:49 postgres/win-ilt1arj8a9c@
> renew until 09/03/20 15:06:31
> 09/02/20 15:07:06 09/03/20 01:06:49 postgres/win-ilt1arj8a9c(at)PGADMIN(dot)ORG
> renew until 09/03/20 15:06:31
>
> However, If I try to login using host + gss in the pg_hba.conf file, I then
> get:
>
> C:\pg>bin\psql postgres
> psql: error: could not connect to server: SSPI continuation error: No
> credentials are available in the security package
> (8009030e)
This is with PG compiled with GSS on the client side and using MIT KfW?
This particular error from SSPI seems to possibly be coming from the
constrained delegation system. While not directly about this issue,
Microsoft has some documentation about configuring constrained
delegation (and how to turn it off) here:
Now, we aren't actually delegating credentials here, so it seems a bit
odd for it to be complaining about that, but perhaps it's throwing this
error because the MIT KfW library has no clue about constrained
delegation and therefore wouldn't be trying to enforce it.
> If I try to use hostgssenc + gss, it looks like it's not even trying to
> encrypt:
>
> C:\pg>bin\psql postgres
> psql: error: could not connect to server: FATAL: no pg_hba.conf entry for
> host "::1", user "dpage", database "postgres", SSL off
>
> Any ideas?
If it's not trying then I would be suspicious that the
gss_acquire_creds() call is saying that there isn't a credential cache,
though that would be a bit odd given that klist seems to be working.
Would certainly be interesting to see if 1.18.2 changes anything in this
regard.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2020-09-02 18:13:03 | PostgreSQL 13 Release Timeline |
Previous Message | Alvaro Herrera | 2020-09-02 17:56:26 | Re: builtin functions, parameter names and psql's \df |