Thread: Kerberos support broken on MSVC builds for Windows x64?

I was experimenting with building with MIT Kerberos support on 64 bit Windows using MSVC and ran into a number of linker errors along the lines of:

"C:\Users\dpage\Downloads\postgresql-12.4\pgsql.sln" (default target) (1) ->
"C:\Users\dpage\Downloads\postgresql-12.4\zic.vcxproj" (default target) (2) ->
(Link target) ->
  LINK : fatal error LNK1181: cannot open input file 'C:\Progra~1\MIT\Kerberos\lib.obj' [C:\Users\dpage\Downloads\postgresql-12.4\zic.vcxproj]

That was after I had to manually add the include and lib paths in buildenv.pl. Diving in a bit further I found a couple of things:

1) The only buildfarm machine doing 64bit Windows Kerberos enabled builds with MSVC is hammerkop. It enables it by setting the "krb5" option in config.pl, however, as far as I can see (going back to 9.5), the option is actually "gss". I can't see any sign in the log for the make step that it actually is making any attempt to build with Kerberos, despite the UI showing the icon for it.

2) I can't find anything in the MSVC build scripts in src/tools/msvc to deal with 64bit Kerberos builds - Solution.pm seems to unconditionally try to link with the 32bit libraries (e.g. lib/i386/krb5_32.lib instead of lib/amd64/krb5_64.lib).

I'm assuming noone has tried a build with 64bit Kerberos, or am I missing something?

Sidenote: I'm not sure even a 32bit Kerberos build will work, as Solution.pm assumes the headers are in $self->{options}->{gss} . '\inc\krb5', however in at least the latest installer from MIT they're actually in $self->{options}->{gss} . '\include'.

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> Attached is a patch against 12.4 for the build system in case anyone wants
> to play (I'll do it properly against the head branch later). I'm guessing
> this will work for < 12, as with 12 I'm now getting the following which
> looks like it's related to GSS encryption:
>
> "C:\Users\dpage\Downloads\postgresql-12.4\pgsql.sln" (default target) (1) ->
> "C:\Users\dpage\Downloads\postgresql-12.4\pgcrypto.vcxproj" (default
> target) (2) ->
> "C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj" (default
> target) (3) ->
> (Link target) ->
>   be-secure-gssapi.obj : error LNK2019: unresolved external symbol setenv
> referenced in function secure_open_gssapi
> [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
>   .\Release\postgres\postgres.exe : fatal error LNK1120: 1 unresolved
> externals [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
>
> I'll dig into that some more.

Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
used under Windows.  If you're successful, I don't have any issue
helping to make that work, though I'm curious if you're trying to build
with MIT KfW (which is rather ancient these days, being based on krb5
1.13 and not updated since..) or with a more current release...?

Of course, it'd be good to get a buildfarm animal in place that's
actually testing this if we're going to make it work.

Regarding the setenv() call, should be able to use pgwin32_putenv() in
place on Windows, I'd think..?

Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
used under Windows. 

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost <sfrost@snowman.net> wrote:
> > * Dave Page (dpage@pgadmin.org) wrote:
> > > Attached is a patch against 12.4 for the build system in case anyone
> > wants
> > > to play (I'll do it properly against the head branch later). I'm guessing
> > > this will work for < 12, as with 12 I'm now getting the following which
> > > looks like it's related to GSS encryption:
> > >
> > > "C:\Users\dpage\Downloads\postgresql-12.4\pgsql.sln" (default target)
> > (1) ->
> > > "C:\Users\dpage\Downloads\postgresql-12.4\pgcrypto.vcxproj" (default
> > > target) (2) ->
> > > "C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj" (default
> > > target) (3) ->
> > > (Link target) ->
> > >   be-secure-gssapi.obj : error LNK2019: unresolved external symbol setenv
> > > referenced in function secure_open_gssapi
> > > [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
> > >   .\Release\postgres\postgres.exe : fatal error LNK1120: 1 unresolved
> > > externals [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
> > >
> > > I'll dig into that some more.
> >
> > Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
> > used under Windows.  If you're successful, I don't have any issue
> > helping to make that work, though I'm curious if you're trying to build
> > with MIT KfW (which is rather ancient these days, being based on krb5
> > 1.13 and not updated since..) or with a more current release...?
>
> I'm currently using the KFW 4.1 build from MIT. I've tried building it
> myself but it requires a very old toolchain (which defeated the point of
> what I was trying to do at the time).

> I haven't yet looked to see if the source for krb5-1.8.2 will build or even
> has the right bits in it for Windows - as I'm sure you know MIT seem to
> maintain an entirely different version for Windows for which I assume
> there's a reason.

I'm a bit confused as to why you'd consider trying 1.8.2- did you mean
1.18.2 there, perhaps..? 

That's what I would think to try, since, as I
understand it from following the Kerberos Dev list (which is pretty
responsive...) has been updated to work with newer Windows build
toolchains.

> > Of course, it'd be good to get a buildfarm animal in place that's
> > actually testing this if we're going to make it work.
>
> Fixing the config on hamerkop should deal with that I think. Though I am
> confused as to why the Buildfarm UI thinks it has Kerberos support enabled
> - did we change the config parameter from krb5 to gss some time prior to
> 9.5? If so, that could explain it.

Looks to be run by SRA OSS..  Perhaps reaching out to them to ask about
it would help?

> > Regarding the setenv() call, should be able to use pgwin32_putenv() in
> > place on Windows, I'd think..?
>
> Right, I imagine so. It's on my todo...

Alright.

Thanks,

Stephen

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?

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

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.

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

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

Greetings,

* Dave Page (dpage@pgadmin.org) wrote:
> On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost <sfrost@snowman.net> wrote:
> > * Dave Page (dpage@pgadmin.org) wrote:
> > > Attached is a patch against 12.4 for the build system in case anyone
> > wants
> > > to play (I'll do it properly against the head branch later). I'm guessing
> > > this will work for < 12, as with 12 I'm now getting the following which
> > > looks like it's related to GSS encryption:
> > >
> > > "C:\Users\dpage\Downloads\postgresql-12.4\pgsql.sln" (default target)
> > (1) ->
> > > "C:\Users\dpage\Downloads\postgresql-12.4\pgcrypto.vcxproj" (default
> > > target) (2) ->
> > > "C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj" (default
> > > target) (3) ->
> > > (Link target) ->
> > >   be-secure-gssapi.obj : error LNK2019: unresolved external symbol setenv
> > > referenced in function secure_open_gssapi
> > > [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
> > >   .\Release\postgres\postgres.exe : fatal error LNK1120: 1 unresolved
> > > externals [C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
> > >
> > > I'll dig into that some more.
> >
> > Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
> > used under Windows.  If you're successful, I don't have any issue
> > helping to make that work, though I'm curious if you're trying to build
> > with MIT KfW (which is rather ancient these days, being based on krb5
> > 1.13 and not updated since..) or with a more current release...?
>
> I'm currently using the KFW 4.1 build from MIT. I've tried building it
> myself but it requires a very old toolchain (which defeated the point of
> what I was trying to do at the time).

> I haven't yet looked to see if the source for krb5-1.8.2 will build or even
> has the right bits in it for Windows - as I'm sure you know MIT seem to
> maintain an entirely different version for Windows for which I assume
> there's a reason.

I'm a bit confused as to why you'd consider trying 1.8.2- did you mean
1.18.2 there, perhaps..? 

Yes, typo.

 

That's what I would think to try, since, as I
understand it from following the Kerberos Dev list (which is pretty
responsive...) has been updated to work with newer Windows build
toolchains.

OK, will try to do that tomorrow.

Thanks!

So having rebuilt PostgreSQL against that, I'm now in the situation where the server never even attempts to get a ticket as far as I can see, and psql just crashes with nothing more than a useless error in the event log:

Faulting application name: psql.exe, version: 14.0.0.20246, time stamp: 0x5f50e477
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000
Faulting process id: 0xd10
Faulting application start time: 0x01d681f189a17360
Faulting application path: C:\pg\bin\psql.exe
Faulting module path: unknown
Report Id: eb68d787-1c82-420d-8878-bc0648932a5d
Faulting package full name:
Faulting package-relative application ID: 

So I'm going to have to break out the debugger, though I suspect this may require more effort than I have time for right now.