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'.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
On Tue, Sep 1, 2020 at 4:22 PM Dave Page <dpage@pgadmin.org> wrote:
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'.
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.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
Attachments:
msvc64-kerberos.diffapplication/octet-stream; name=msvc64-kerberos.diffDownload
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 9d2345689a..b974b149ee 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -729,10 +729,19 @@ sub AddProject
}
if ($self->{options}->{gss})
{
- $proj->AddIncludeDir($self->{options}->{gss} . '\inc\krb5');
- $proj->AddLibrary($self->{options}->{gss} . '\lib\i386\krb5_32.lib');
- $proj->AddLibrary($self->{options}->{gss} . '\lib\i386\comerr32.lib');
- $proj->AddLibrary($self->{options}->{gss} . '\lib\i386\gssapi32.lib');
+ $proj->AddIncludeDir($self->{options}->{gss} . '\include');
+ if ($self->{platform} eq 'Win32')
+ {
+ $proj->AddLibrary($self->{options}->{gss} . '\lib\i386\krb5_32.lib');
+ $proj->AddLibrary($self->{options}->{gss} . '\lib\i386\comerr32.lib');
+ $proj->AddLibrary($self->{options}->{gss} . '\lib\i386\gssapi32.lib');
+ }
+ else
+ {
+ $proj->AddLibrary($self->{options}->{gss} . '\lib\amd64\krb5_64.lib');
+ $proj->AddLibrary($self->{options}->{gss} . '\lib\amd64\comerr64.lib');
+ $proj->AddLibrary($self->{options}->{gss} . '\lib\amd64\gssapi64.lib');
+ }
}
if ($self->{options}->{iconv})
{
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..?
Thanks,
Stephen
Hi
On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost <sfrost@snowman.net> wrote:
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...?
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.
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.
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...
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
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
Hi
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.
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:
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)
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?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
Attachments:
msvc64-kerberos-v2.diffapplication/octet-stream; name=msvc64-kerberos-v2.diffDownload
��d i f f - - g i t a / s r c / b a c k e n d / l i b p q / b e - s e c u r e - g s s a p i . c b / s r c / b a c k e n d / l i b p q / b e - s e c u r e - g s s a p i . c
i n d e x 6 4 4 2 7 f 1 8 5 b . . 1 b 3 0 a 2 a 1 2 5 1 0 0 6 4 4
- - - a / s r c / b a c k e n d / l i b p q / b e - s e c u r e - g s s a p i . c
+ + + b / s r c / b a c k e n d / l i b p q / b e - s e c u r e - g s s a p i . c
@ @ - 4 9 0 , 7 + 4 9 0 , 2 1 @ @ s e c u r e _ o p e n _ g s s a p i ( P o r t * p o r t )
* d o e s n ' t s u p p o r t t h e c r e d s t o r e e x t e n s i o n s , s o u s e t h e e n v v a r .
* /
i f ( p g _ k r b _ s e r v e r _ k e y f i l e ! = N U L L & & s t r l e n ( p g _ k r b _ s e r v e r _ k e y f i l e ) > 0 )
- s e t e n v ( " K R B 5 _ K T N A M E " , p g _ k r b _ s e r v e r _ k e y f i l e , 1 ) ;
+ {
+ s i z e _ t k t _ l e n = s t r l e n ( p g _ k r b _ s e r v e r _ k e y f i l e ) + 1 4 ;
+ c h a r * k t _ p a t h = m a l l o c ( k t _ l e n ) ;
+
+ i f ( ! k t _ p a t h | |
+ s n p r i n t f ( k t _ p a t h , k t _ l e n , " K R B 5 _ K T N A M E = % s " ,
+ p g _ k r b _ s e r v e r _ k e y f i l e ) ! = k t _ l e n - 2 | |
+ p u t e n v ( k t _ p a t h ) ! = 0 )
+ {
+ e r e p o r t ( L O G ,
+ ( e r r c o d e ( E R R C O D E _ O U T _ O F _ M E M O R Y ) ,
+ e r r m s g ( " o u t o f m e m o r y " ) ) ) ;
+ r e t u r n S T A T U S _ E R R O R ;
+ }
+ }
w h i l e ( t r u e )
{
d i f f - - g i t a / s r c / t o o l s / m s v c / S o l u t i o n . p m b / s r c / t o o l s / m s v c / S o l u t i o n . p m
i n d e x b c 8 9 0 4 7 3 2 f . . 0 c 6 0 0 3 7 c e 9 1 0 0 6 4 4
- - - a / s r c / t o o l s / m s v c / S o l u t i o n . p m
+ + + b / s r c / t o o l s / m s v c / S o l u t i o n . p m
@ @ - 1 0 1 1 , 1 0 + 1 0 1 1 , 1 9 @ @ s u b A d d P r o j e c t
}
i f ( $ s e l f - > { o p t i o n s } - > { g s s } )
{
- $ p r o j - > A d d I n c l u d e D i r ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ i n c \ k r b 5 ' ) ;
- $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ i 3 8 6 \ k r b 5 _ 3 2 . l i b ' ) ;
- $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ i 3 8 6 \ c o m e r r 3 2 . l i b ' ) ;
- $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ i 3 8 6 \ g s s a p i 3 2 . l i b ' ) ;
+ $ p r o j - > A d d I n c l u d e D i r ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ i n c l u d e ' ) ;
+ i f ( $ s e l f - > { p l a t f o r m } e q ' W i n 3 2 ' )
+ {
+ $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ i 3 8 6 \ k r b 5 _ 3 2 . l i b ' ) ;
+ $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ i 3 8 6 \ c o m e r r 3 2 . l i b ' ) ;
+ $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ i 3 8 6 \ g s s a p i 3 2 . l i b ' ) ;
+ }
+ e l s e
+ {
+ $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ a m d 6 4 \ k r b 5 _ 6 4 . l i b ' ) ;
+ $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ a m d 6 4 \ c o m e r r 6 4 . l i b ' ) ;
+ $ p r o j - > A d d L i b r a r y ( $ s e l f - > { o p t i o n s } - > { g s s } . ' \ l i b \ a m d 6 4 \ g s s a p i 6 4 . l i b ' ) ;
+ }
}
i f ( $ s e l f - > { o p t i o n s } - > { i c o n v } )
{
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 symbolsetenv
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!
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 supportenabled
- 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
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
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.ORGValid 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:31However, 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 offAny 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
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. Usingthat,
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.ORGValid 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: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 entryfor
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
On Wed, Sep 2, 2020 at 5:21 PM Dave Page <dpage@pgadmin.org> wrote:
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 symbolsetenv
referenced in function secure_open_gssapi
[C:\Users\dpage\Downloads\postgresql-12.4\postgres.vcxproj]
.\Release\postgres\postgres.exe : fatal error LNK1120: 1unresolved
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 tobuild
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!
OK, so 1.18.2 builds OK. It's a bit of a faff, but nothing major. It seems
to work fine as a standalone set of tools.
Of course, they've changed the installation paths again - they've dropped
the i386 and amd64 parts from the library path :-/
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.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
On Thu, Sep 3, 2020 at 4:15 PM Dave Page <dpage@pgadmin.org> wrote:
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.
Yeah, this is almost certainly well beyond what I have the time to figure
out. Happy to do any testing etc. that may be needed, but I think this
needs someone familiar with the GSS API to take the lead.
Here's what I got from psql in the debugger:
Exception thrown at 0x0000000000000000 in psql.exe: 0xC0000005: Access
violation executing location 0x0000000000000000. occurred
0000000000000000()
krb5_64.dll!0000000051942807()
krb5_64.dll!000000005194214b()
krb5_64.dll!0000000051980611()
krb5_64.dll!00000000519766cb()
krb5_64.dll!00000000519670ff()
gssapi64.dll!0000000051bb1839()
gssapi64.dll!0000000051bb48e4()
gssapi64.dll!0000000051bb4575()
gssapi64.dll!0000000051b993df()
libpq.dll!pqsecure_open_gss(pg_conn * conn) Line 632
at
c:\users\dpage\downloads\postgresql\src\interfaces\libpq\fe-secure-gssapi.c(632)
libpq.dll!PQconnectPoll(pg_conn * conn) Line 3173
at
c:\users\dpage\downloads\postgresql\src\interfaces\libpq\fe-connect.c(3173)
libpq.dll!connectDBComplete(pg_conn * conn) Line 2187
at
c:\users\dpage\downloads\postgresql\src\interfaces\libpq\fe-connect.c(2187)
libpq.dll!PQconnectdbParams(const char * const * keywords, const char *
const * values, int expand_dbname) Line 655
at
c:\users\dpage\downloads\postgresql\src\interfaces\libpq\fe-connect.c(655)
psql.exe!main(int argc, char * * argv) Line 266
at c:\users\dpage\downloads\postgresql\src\bin\psql\startup.c(266)
[External Code]
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake