Re: Kerberos support broken on MSVC builds for Windows x64? - Mailing list pgsql-hackers

From Dave Page
Subject Re: Kerberos support broken on MSVC builds for Windows x64?
Date
Msg-id CA+OCxow1V-s+9BkQOLX1qzdZciBTVkgBiLnDEWyGVfsvj5aQyw@mail.gmail.com
Whole thread Raw
In response to Re: Kerberos support broken on MSVC builds for Windows x64?  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Hi

On Wed, Sep 2, 2020 at 7:08 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Wed, Sep 2, 2020 at 9:05 AM Dave Page <dpage@pgadmin.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?

Yes, with the workstation configured to authenticate windows login with Kerberos (e.g. https://www.garyhawkins.me.uk/non-domain-mit-kerberos-logins-on-windows-10/)
 

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..?

Ahh, probably. I'm just using host files on these VMs, but I'll bet I forgot to add the client to the kdc's file. Will try that tomorrow.
 

> C:\pg>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
> Ticket cache: API:Initial default ccache
> Default principal: dpage@PGADMIN.ORG
>
> Valid starting     Expires            Service principal
> 09/02/20 15:06:49  09/03/20 01:06:49  krbtgt/PGADMIN.ORG@PGADMIN.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@PGADMIN.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?

Yes.
 

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:

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Set-up-hosts-for-live-migration-without-Failover-Clustering

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.

OK, I'll look into that.
 

> 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.

I'll let you know how that goes. Thanks for the tips! 

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: PostgreSQL 13 Release Timeline
Next
From: Tom Lane
Date:
Subject: Re: Allow continuations in "pg_hba.conf" files