Обсуждение: GSS Authentication

Поиск
Список
Период
Сортировка

GSS Authentication

От
greigwise@comcast.net
Дата:
I'm trying to get my PostgreSQL server on Linux configured so that I can connect from a Windows client using GSS Authentication against Active Directory.  I found some helpful references on how to do this, but I'm still coming up short.  To summarize what I've done so far by way of configuration:

1) On the Linux server, setup my krb5.conf file such that I can get a ticket from AD using kinit and confirm using klist.
2) Setup a new account in AD and used ktpass to create a keytab file for the SPN.
3) Copied the keytab file onto my postgres server and updated my postgresql.conf file appropriately (set the krb_server_keyfile to point to the file I just created.)

Then I wrote a little test Perl program to connect to my postgres database. 

use DBI;
use strict;

my $dbh = DBI->connect('DBI:Pg:dbname=postgres;host=host.domain.com;krbsrvname=POSTGRES') or die DBI->errstr;

When I try to run the Perl program I get this error:

DBI connect('dbname=postgres;host=host.domain.com;krbsrvname=POSTGRES')
failed: FATAL:  accepting GSS security context failed
DETAIL:  Miscellaneous failure: Unknown code ggss 3 at g.pl line 4
FATAL:  accepting GSS security context failed
DETAIL:  Miscellaneous failure: Unknown code ggss 3 at g.pl line 4

I then ramped up the debug logging on the postgres side and get this off the server:

2010-06-11 17:23:49 EDTDEBUG:  00000: Processing received GSS token of length 2119
2010-06-11 17:23:49 EDTLOCATION:  pg_GSS_recvauth, auth.c:965
2010-06-11 17:23:49 EDTDEBUG:  00000: gss_accept_sec_context major: 851968, minor: -2045022973, outlen: 0, outflags: 7f
2010-06-11 17:23:49 EDTLOCATION:  pg_GSS_recvauth, auth.c:984
2010-06-11 17:23:49 EDTFATAL:  XX000: accepting GSS security context failed
2010-06-11 17:23:49 EDTDETAIL:  Miscellaneous failure: Unknown code ggss 3
2010-06-11 17:23:49 EDTLOCATION:  pg_GSS_error, auth.c:866

I'm using PostgreSQL 8.4.4 on Enterprise Linux 4.

Can anyone offer any suggestions?

Thanks in advance.
Greig

Re: GSS Authentication

От
Stephen Frost
Дата:
* greigwise@comcast.net (greigwise@comcast.net) wrote:
> 2) Setup a new account in AD and used ktpass to create a keytab file for the SPN.

Did you make sure to use the right service name when creating the
keytab?  Can you do a klist -k on the keytab file and send the output?
Does hostname --fqdn return the correct answer on the server?  If not,
you might need to adjust what PG thinks your FQDN is (there's an option
in postgresql.conf for that too, but I'd recommend trying to fix your
server to return the right answer instead of forcing it).

> 3) Copied the keytab file onto my postgres server and updated my postgresql.conf file appropriately (set the
krb_server_keyfileto point to the file I just created.)  

You'll probably also need to change the default service name to POSTGRES
instead of postgres, in postgresql.conf too, klist -k should help figure
that out.

> Then I wrote a little test Perl program to connect to my postgres database.

Can you test with psql locally first?  Make sure that when you *try* to
connect, it acquires the service princ from the KDC (check using klist)
and then see if it is actually *able* to authenticate to the server.
You'll need to set the appropriate environment variables on both Linux
and Windows tho for libpq to know what the right service name is (again,
POSTGRES instead of postgres, probably).

You may also need to make sure that your default realm is set correctly
and that your reverse DNS is working.  Also, can you look in the PG
server-side logs and see what errors are being reported there?  There
may be some during startup or when the client tries to connect that
would be useful.

    Thanks,

        Stephen
Вложения

Re: GSS Authentication

От
Bryan Montgomery
Дата:
I've been trying this as well off and on. In my case I'm not convinced the AD configuration is correct (And someone else manages that).
 
Can you use kinit with the key tab options to get a good response from the server? I think I should be able to do this ..
$ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
kinit(v5): Preauthentication failed while getting initial credentials
 
I'd be interested to know if you get something different - and the steps you went through on the AD side.
 
Bryan.

On Fri, Jun 11, 2010 at 5:51 PM, <greigwise@comcast.net> wrote:
I'm trying to get my PostgreSQL server on Linux configured so that I can connect from a Windows client using GSS Authentication against Active Directory.  I found some helpful references on how to do this, but I'm still coming up short.  To summarize what I've done so far by way of configuration:

1) On the Linux server, setup my krb5.conf file such that I can get a ticket from AD using kinit and confirm using klist.
2) Setup a new account in AD and used ktpass to create a keytab file for the SPN.
3) Copied the keytab file onto my postgres server and updated my postgresql.conf file appropriately (set the krb_server_keyfile to point to the file I just created.)

Then I wrote a little test Perl program to connect to my postgres database. 

use DBI;
use strict;

my $dbh = DBI->connect('DBI:Pg:dbname=postgres;host=host.domain.com;krbsrvname=POSTGRES') or die DBI->errstr;

When I try to run the Perl program I get this error:

DBI connect('dbname=postgres;host=host.domain.com;krbsrvname=POSTGRES')
failed: FATAL:  accepting GSS security context failed
DETAIL:  Miscellaneous failure: Unknown code ggss 3 at g.pl line 4
FATAL:  accepting GSS security context failed
DETAIL:  Miscellaneous failure: Unknown code ggss 3 at g.pl line 4

I then ramped up the debug logging on the postgres side and get this off the server:

2010-06-11 17:23:49 EDTDEBUG:  00000: Processing received GSS token of length 2119
2010-06-11 17:23:49 EDTLOCATION:  pg_GSS_recvauth, auth.c:965
2010-06-11 17:23:49 EDTDEBUG:  00000: gss_accept_sec_context major: 851968, minor: -2045022973, outlen: 0, outflags: 7f
2010-06-11 17:23:49 EDTLOCATION:  pg_GSS_recvauth, auth.c:984
2010-06-11 17:23:49 EDTFATAL:  XX000: accepting GSS security context failed
2010-06-11 17:23:49 EDTDETAIL:  Miscellaneous failure: Unknown code ggss 3
2010-06-11 17:23:49 EDTLOCATION:  pg_GSS_error, auth.c:866

I'm using PostgreSQL 8.4.4 on Enterprise Linux 4.

Can anyone offer any suggestions?

Thanks in advance.
Greig

Re: GSS Authentication

От
Stephen Frost
Дата:
Bryan,

* Bryan Montgomery (monty@english.net) wrote:
> On Sat, Jun 12, 2010 at 12:58 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Can you elaborate on the DNS requirements? How would I check the reverse
> DNS? I assume just pinging both server by hostname?

Kerberos depends on reverse DNS.  Reverse DNS is IP Address -> DNS Name
(rather than forward/regular DNS, which is Name -> IP).  Specifically,
when a Kerberos client connects to a server, it will take the IP address
of the host it connected to and try to find the name, it will then use
*that* name to determine what ticket to request from the KDC.

Realm: EXAMPLE.COM
Client system: client.example.com
Client IP 10.10.10.1

Server system: server.example.com
Server IP: 10.10.10.20

Client connects to server and looks up "10.10.10.20" to find out the
server's name is "server.example.com", it will then ask the KDC for
a "postgres/server.example.com@EXAMPLE.COM" ticket.  This allows the
server to have other aliases (eg: database.example.com) and for the
client to use that alias to connect to, but then only need 1 principal
(the server.example.com) in the KDC.

    Thanks,

        Stephen
Вложения

Re: GSS Authentication

От
Stephen Frost
Дата:
* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

    Thanks,

        Stephen
Вложения

Re: GSS Authentication

От
Bryan Montgomery
Дата:
Hi Steven,
Thanks for the info here. In particular,

On Sat, Jun 12, 2010 at 12:58 AM, Stephen Frost <sfrost@snowman.net> wrote:
You may also need to make sure that your default realm is set correctly
and that your reverse DNS is working.  Also, can you look in the PG
server-side logs and see what errors are being reported there?  There
may be some during startup or when the client tries to connect that
would be useful.

       Thanks,

               Stephen

Can you elaborate on the DNS requirements? How would I check the reverse DNS? I assume just pinging both server by hostname?
 
Thanks - Bryan.

Re: GSS Authentication

От
greigwise@comcast.net
Дата:

Thanks for the help.

 

In response to your questions, I did make sure the service name was right.

klist -k on the keytab file gives:

 

KVNO Principal
---- --------------------------------------------------------------------------
   3 POSTGRES/hostname.domain.com@DOMAIN.COM

 

 

I replaced our real domain with an example obviously, but that's what it looks like.

I'm thinking it looks correct. 

 

By testing with psql locally first, do you mean running psql right on the postgres server itself?  To test the GSS authentication?  I tried to set the local connections in the pg_hba.conf to use gss authentication locally, but then when I tried to restart postgres, the logs said that GSS authentication wasn't allowed for local connections (see log message below):

 

2010-06-14 14:42:24 EDTLOG:  F0000: gssapi authentication is not supported on local sockets

 

I did change the default service name to POSTGRES instead of postgres.

Reverse DNS is working and I think the default realm is right.  I'm a little unclear on exactly what that should be, but I'm thinking that based on the example above it should be something like "domain.com". 

 

I did give the server side logs in my original message, but I'll include more.  So, in this log entry I'll paste below (it's a little lengthy), we have a startup, then a failed connection from the windows client, then a shutdown.

 

What should I try next?  Thanks for the help.

 

Greig Wise

 

--------

 

2010-06-14 15:12:21 EDTLOG:  00000: database system was shut down at 2010-06-14 15:12:08 EDT
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5243
2010-06-14 15:12:21 EDTDEBUG:  00000: checkpoint record is at 1/BD000020
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5340
2010-06-14 15:12:21 EDTDEBUG:  00000: redo record is at 1/BD000020; shutdown TRUE
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5366
2010-06-14 15:12:21 EDTDEBUG:  00000: next transaction ID: 0/696; next OID: 16400
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5370
2010-06-14 15:12:21 EDTDEBUG:  00000: next MultiXactId: 1; next MultiXactOffset: 0
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5373
2010-06-14 15:12:21 EDTDEBUG:  00000: transaction ID wrap limit is 2147484295, limited by database "template1"
2010-06-14 15:12:21 EDTLOCATION:  SetTransactionIdLimit, varsup.c:285
2010-06-14 15:12:21 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:21 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:21 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:21 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:21 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:21 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:21 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:21 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:21 EDTLOG:  00000: autovacuum launcher started
2010-06-14 15:12:21 EDTLOCATION:  AutoVacLauncherMain, autovacuum.c:529
2010-06-14 15:12:21 EDTLOG:  00000: database system is ready to accept connections
2010-06-14 15:12:21 EDTLOCATION:  reaper, postmaster.c:2326
2010-06-14 15:12:26 EDTDEBUG:  00000: forked new backend, pid=4750 socket=8
2010-06-14 15:12:26 EDTLOCATION:  BackendStartup, postmaster.c:3085
2010-06-14 15:12:26 EDTDEBUG:  00000: Processing received GSS token of length 2007
2010-06-14 15:12:26 EDTLOCATION:  pg_GSS_recvauth, auth.c:965
2010-06-14 15:12:26 EDTDEBUG:  00000: gss_accept_sec_context major: 851968, minor: -2045022973, outlen: 0, outflags: 7f
2010-06-14 15:12:26 EDTLOCATION:  pg_GSS_recvauth, auth.c:984
2010-06-14 15:12:26 EDTFATAL:  XX000: accepting GSS security context failed
2010-06-14 15:12:26 EDTDETAIL:  Miscellaneous failure: Unknown code ggss 3
2010-06-14 15:12:26 EDTLOCATION:  pg_GSS_error, auth.c:866
2010-06-14 15:12:26 EDTDEBUG:  00000: shmem_exit(1): 0 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:26 EDTDEBUG:  00000: proc_exit(1): 1 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:26 EDTDEBUG:  00000: exit(1)
2010-06-14 15:12:26 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:26 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:26 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:26 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:26 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:26 EDTDEBUG:  00000: server process (PID 4750) exited with exit code 1
2010-06-14 15:12:26 EDTLOCATION:  LogChildExit, postmaster.c:2707
2010-06-14 15:12:31 EDTDEBUG:  00000: postmaster received signal 15
2010-06-14 15:12:31 EDTLOCATION:  pmdie, postmaster.c:2090
2010-06-14 15:12:31 EDTLOG:  00000: received smart shutdown request
2010-06-14 15:12:31 EDTLOCATION:  pmdie, postmaster.c:2105
2010-06-14 15:12:31 EDTLOG:  00000: autovacuum launcher shutting down
2010-06-14 15:12:31 EDTLOCATION:  AutoVacLauncherMain, autovacuum.c:760
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 1 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTLOG:  00000: shutting down
2010-06-14 15:12:31 EDTLOCATION:  ShutdownXLOG, xlog.c:6234
2010-06-14 15:12:31 EDTDEBUG:  00000: executing archive command "cp pg_xlog/0000000100000001000000BD /postgresdb/log_arch/0000000100000001000000BD </dev/null"
2010-06-14 15:12:31 EDTLOCATION:  pgarch_archiveXlog, pgarch.c:544
2010-06-14 15:12:31 EDTDEBUG:  00000: archived transaction log file "0000000100000001000000BD"
2010-06-14 15:12:31 EDTLOCATION:  pgarch_archiveXlog, pgarch.c:612
2010-06-14 15:12:31 EDTDEBUG:  00000: recycled transaction log file "0000000100000001000000BC"
2010-06-14 15:12:31 EDTLOCATION:  RemoveOldXlogFiles, xlog.c:3083
2010-06-14 15:12:31 EDTLOG:  00000: database system is shut down
2010-06-14 15:12:31 EDTLOCATION:  ShutdownXLOG, xlog.c:6256
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: logger shutting down
2010-06-14 15:12:31 EDTLOCATION:  SysLoggerMain, syslogger.c:446
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183

 


----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 12:58:03 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> 2) Setup a new account in AD and used ktpass to create a keytab file for the SPN.

Did you make sure to use the right service name when creating the
keytab?  Can you do a klist -k on the keytab file and send the output?
Does hostname --fqdn return the correct answer on the server?  If not,
you might need to adjust what PG thinks your FQDN is (there's an option
in postgresql.conf for that too, but I'd recommend trying to fix your
server to return the right answer instead of forcing it).

> 3) Copied the keytab file onto my postgres server and updated my postgresql.conf file appropriately (set the krb_server_keyfile to point to the file I just created.)

You'll probably also need to change the default service name to POSTGRES
instead of postgres, in postgresql.conf too, klist -k should help figure
that out.

> Then I wrote a little test Perl program to connect to my postgres database.

Can you test with psql locally first?  Make sure that when you *try* to
connect, it acquires the service princ from the KDC (check using klist)
and then see if it is actually *able* to authenticate to the server.
You'll need to set the appropriate environment variables on both Linux
and Windows tho for libpq to know what the right service name is (again,
POSTGRES instead of postgres, probably).

You may also need to make sure that your default realm is set correctly
and that your reverse DNS is working.  Also, can you look in the PG
server-side logs and see what errors are being reported there?  There
may be some during startup or when the client tries to connect that
would be useful.

        Thanks,

                Stephen

Re: GSS Authentication

От
greigwise@comcast.net
Дата:

One other thing possibly worth noting.... I tried to connect to the Postgres DB using pgAdmin III and it gives a very similar error to the test perl program that I wrote:

 

Error connecting to the server: FATAL: accepting GSS security context failed DETAIL: Miscellaneous failure: Unknown code ggss 3

 

So, it seems as if it must be something on the server side as 2 different clients are failing in the same way I think.

 

Thanks again.

 

Greig

 


----- Original Message -----
From: greigwise@comcast.net
To: "Stephen Frost" <sfrost@snowman.net>
Cc: pgsql-general@postgresql.org
Sent: Monday, June 14, 2010 3:22:36 PM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

p { margin: 0; }

Thanks for the help.

 

In response to your questions, I did make sure the service name was right.

klist -k on the keytab file gives:

 

KVNO Principal
---- --------------------------------------------------------------------------
   3 POSTGRES/hostname.domain.com@DOMAIN.COM

 

 

I replaced our real domain with an example obviously, but that's what it looks like.

I'm thinking it looks correct. 

 

By testing with psql locally first, do you mean running psql right on the postgres server itself?  To test the GSS authentication?  I tried to set the local connections in the pg_hba.conf to use gss authentication locally, but then when I tried to restart postgres, the logs said that GSS authentication wasn't allowed for local connections (see log message below):

 

2010-06-14 14:42:24 EDTLOG:  F0000: gssapi authentication is not supported on local sockets

 

I did change the default service name to POSTGRES instead of postgres.

Reverse DNS is working and I think the default realm is right.  I'm a little unclear on exactly what that should be, but I'm thinking that based on the example above it should be something like "domain.com". 

 

I did give the server side logs in my original message, but I'll include more.  So, in this log entry I'll paste below (it's a little lengthy), we have a startup, then a failed connection from the windows client, then a shutdown.

 

What should I try next?  Thanks for the help.

 

Greig Wise

 

--------

 

2010-06-14 15:12:21 EDTLOG:  00000: database system was shut down at 2010-06-14 15:12:08 EDT
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5243
2010-06-14 15:12:21 EDTDEBUG:  00000: checkpoint record is at 1/BD000020
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5340
2010-06-14 15:12:21 EDTDEBUG:  00000: redo record is at 1/BD000020; shutdown TRUE
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5366
2010-06-14 15:12:21 EDTDEBUG:  00000: next transaction ID: 0/696; next OID: 16400
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5370
2010-06-14 15:12:21 EDTDEBUG:  00000: next MultiXactId: 1; next MultiXactOffset: 0
2010-06-14 15:12:21 EDTLOCATION:  StartupXLOG, xlog.c:5373
2010-06-14 15:12:21 EDTDEBUG:  00000: transaction ID wrap limit is 2147484295, limited by database "template1"
2010-06-14 15:12:21 EDTLOCATION:  SetTransactionIdLimit, varsup.c:285
2010-06-14 15:12:21 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:21 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:21 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:21 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:21 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:21 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:21 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:21 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:21 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:21 EDTLOG:  00000: autovacuum launcher started
2010-06-14 15:12:21 EDTLOCATION:  AutoVacLauncherMain, autovacuum.c:529
2010-06-14 15:12:21 EDTLOG:  00000: database system is ready to accept connections
2010-06-14 15:12:21 EDTLOCATION:  reaper, postmaster.c:2326
2010-06-14 15:12:26 EDTDEBUG:  00000: forked new backend, pid=4750 socket=8
2010-06-14 15:12:26 EDTLOCATION:  BackendStartup, postmaster.c:3085
2010-06-14 15:12:26 EDTDEBUG:  00000: Processing received GSS token of length 2007
2010-06-14 15:12:26 EDTLOCATION:  pg_GSS_recvauth, auth.c:965
2010-06-14 15:12:26 EDTDEBUG:  00000: gss_accept_sec_context major: 851968, minor: -2045022973, outlen: 0, outflags: 7f
2010-06-14 15:12:26 EDTLOCATION:  pg_GSS_recvauth, auth.c:984
2010-06-14 15:12:26 EDTFATAL:  XX000: accepting GSS security context failed
2010-06-14 15:12:26 EDTDETAIL:  Miscellaneous failure: Unknown code ggss 3
2010-06-14 15:12:26 EDTLOCATION:  pg_GSS_error, auth.c:866
2010-06-14 15:12:26 EDTDEBUG:  00000: shmem_exit(1): 0 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:26 EDTDEBUG:  00000: proc_exit(1): 1 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:26 EDTDEBUG:  00000: exit(1)
2010-06-14 15:12:26 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:26 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:26 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:26 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:26 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:26 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:26 EDTDEBUG:  00000: server process (PID 4750) exited with exit code 1
2010-06-14 15:12:26 EDTLOCATION:  LogChildExit, postmaster.c:2707
2010-06-14 15:12:31 EDTDEBUG:  00000: postmaster received signal 15
2010-06-14 15:12:31 EDTLOCATION:  pmdie, postmaster.c:2090
2010-06-14 15:12:31 EDTLOG:  00000: received smart shutdown request
2010-06-14 15:12:31 EDTLOCATION:  pmdie, postmaster.c:2105
2010-06-14 15:12:31 EDTLOG:  00000: autovacuum launcher shutting down
2010-06-14 15:12:31 EDTLOCATION:  AutoVacLauncherMain, autovacuum.c:760
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 1 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTLOG:  00000: shutting down
2010-06-14 15:12:31 EDTLOCATION:  ShutdownXLOG, xlog.c:6234
2010-06-14 15:12:31 EDTDEBUG:  00000: executing archive command "cp pg_xlog/0000000100000001000000BD /postgresdb/log_arch/0000000100000001000000BD </dev/null"
2010-06-14 15:12:31 EDTLOCATION:  pgarch_archiveXlog, pgarch.c:544
2010-06-14 15:12:31 EDTDEBUG:  00000: archived transaction log file "0000000100000001000000BD"
2010-06-14 15:12:31 EDTLOCATION:  pgarch_archiveXlog, pgarch.c:612
2010-06-14 15:12:31 EDTDEBUG:  00000: recycled transaction log file "0000000100000001000000BC"
2010-06-14 15:12:31 EDTLOCATION:  RemoveOldXlogFiles, xlog.c:3083
2010-06-14 15:12:31 EDTLOG:  00000: database system is shut down
2010-06-14 15:12:31 EDTLOCATION:  ShutdownXLOG, xlog.c:6256
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 2 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: reaping dead processes
2010-06-14 15:12:31 EDTLOCATION:  reaper, postmaster.c:2238
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 3 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: logger shutting down
2010-06-14 15:12:31 EDTLOCATION:  SysLoggerMain, syslogger.c:446
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(0): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(0): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183
2010-06-14 15:12:31 EDTDEBUG:  00000: exit(0)
2010-06-14 15:12:31 EDTLOCATION:  proc_exit, ipc.c:135
2010-06-14 15:12:31 EDTDEBUG:  00000: shmem_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  shmem_exit, ipc.c:211
2010-06-14 15:12:31 EDTDEBUG:  00000: proc_exit(-1): 0 callbacks to make
2010-06-14 15:12:31 EDTLOCATION:  proc_exit_prepare, ipc.c:183

 


----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 12:58:03 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> 2) Setup a new account in AD and used ktpass to create a keytab file for the SPN.

Did you make sure to use the right service name when creating the
keytab?  Can you do a klist -k on the keytab file and send the output?
Does hostname --fqdn return the correct answer on the server?  If not,
you might need to adjust what PG thinks your FQDN is (there's an option
in postgresql.conf for that too, but I'd recommend trying to fix your
server to return the right answer instead of forcing it).

> 3) Copied the keytab file onto my postgres server and updated my postgresql.conf file appropriately (set the krb_server_keyfile to point to the file I just created.)

You'll probably also need to change the default service name to POSTGRES
instead of postgres, in postgresql.conf too, klist -k should help figure
that out.

> Then I wrote a little test Perl program to connect to my postgres database.

Can you test with psql locally first?  Make sure that when you *try* to
connect, it acquires the service princ from the KDC (check using klist)
and then see if it is actually *able* to authenticate to the server.
You'll need to set the appropriate environment variables on both Linux
and Windows tho for libpq to know what the right service name is (again,
POSTGRES instead of postgres, probably).

You may also need to make sure that your default realm is set correctly
and that your reverse DNS is working.  Also, can you look in the PG
server-side logs and see what errors are being reported there?  There
may be some during startup or when the client tries to connect that
would be useful.

        Thanks,

                Stephen

Re: GSS Authentication

От
greigwise@comcast.net
Дата:

As suggested below, I just tried this:

kinit -S POSTGRES/host.domain.com user

(where user is my account name in AD).  That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket.  Doing it this way though, the keytab file doesn't seem to come into play.  Does this point to something in my keytab file being wrong?

I did this: 

klist -ket postgres.keytab

and got:

KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)

That timestamp seems kinda funky, doesn't it?  12/31/69?  That can't be right, can it?

Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: greigwise@comcast.net, pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 8:35:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

        Thanks,

                Stephen
Вложения

Re: GSS Authentication

От
Stephen Frost
Дата:
* greigwise@comcast.net (greigwise@comcast.net) wrote:
> kinit -S POSTGRES/host.domain.com user
>
> (where user is my account name in AD). That then asked for my password and when I entered it, it seemed to work. And
nowklist shows that I have a ticket. Doing it this way though, the keytab file doesn't seem to come into play. Does
thispoint to something in my keytab file being wrong?  

Good that you were able to get a ticket manually.  Next you need to try
getting a client application (eg: psql) to get that same ticket.  Before
you run psql, do:

kdestroy
kinit
export PGKRBSRVNAME=POSTGRES
psql -d postgres -h host.domain.com
klist

And see if you acquired the same ticket you got with the manual klist.

> I did this:
>
> klist -ket postgres.keytab
>
> and got:
>
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)
>
> That timestamp seems kinda funky, doesn't it? 12/31/69? That can't be right, can it?

The timestamp isn't really "right", but it shouldn't really hurt either-
that's just when it was "created".  The encyprtion is crappy though and
might be disabled by default (MIT Kerberos recently started disabling
DES and lower encryption because it's horribly insecure).  Check your
/etc/krb5.conf for permitted_enctypes.  Also, after you get a
POSTGRES/host.domain.com ticket using kinit (or psql), do a klist -e and
see if the encryption type of the ticket you got matches that of the
keytab.  If it doesn't, then you might have created multiple keys for
the same princ on the server (not generally a bad thing), but not
exported and loaded all of them into the keytab on the unix system
(which would be a problem...).

    Thanks,

        Stephen
Вложения

Re: GSS Authentication

От
greigwise@comcast.net
Дата:
OK.  I tried what you suggested.  I pasted the whole sequence of commands and the results below.  As you can see, the connection to postgres still failed, but it looks like it actually acquired the ticket (I think).   What do you make of that?

Thanks again for the help.
Greig


[user@client ~]$ kdestroy
--------------------------------------------------------------------
[user@client ~]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_503)

Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
[user@client ~]$ kinit
Password for user@DOMAIN.COM:
--------------------------------------------------------------------
[user@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: user@DOMAIN.COM

Valid starting     Expires            Service principal
06/15/10 17:16:37  06/16/10 03:16:42  krbtgt/DOMAIN.COM@DOMAIN.COM
        renew until 06/16/10 03:16:37


Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------
[user@client ~]$ psql -d postgres -h server.DOMAIN.COM
psql: FATAL:  accepting GSS security context failed
DETAIL:  Miscellaneous failure: Unknown code krb5 181
--------------------------------------------------------------------
[user@client ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: user@DOMAIN.COM

Valid starting     Expires            Service principal
06/15/10 17:16:37  06/16/10 03:16:42  krbtgt/DOMAIN.COM@DOMAIN.COM
        renew until 06/16/10 03:16:37
06/15/10 17:17:01  06/16/10 03:16:42  POSTGRES/server.DOMAIN.COM@DOMAIN.COM
        renew until 06/16/10 03:16:37


Kerberos 4 ticket cache: /tmp/tkt503
klist: You have no tickets cached
--------------------------------------------------------------------


----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: pgsql-general@postgresql.org, "Bryan Montgomery" <monty@english.net>
Sent: Tuesday, June 15, 2010 4:25:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> kinit -S POSTGRES/host.domain.com user
>
> (where user is my account name in AD). That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket. Doing it this way though, the keytab file doesn't seem to come into play. Does this point to something in my keytab file being wrong?

Good that you were able to get a ticket manually.  Next you need to try
getting a client application (eg: psql) to get that same ticket.  Before
you run psql, do:

kdestroy
kinit
export PGKRBSRVNAME=POSTGRES
psql -d postgres -h host.domain.com
klist

And see if you acquired the same ticket you got with the manual klist.

> I did this:
>
> klist -ket postgres.keytab
>
> and got:
>
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)
>
> That timestamp seems kinda funky, doesn't it? 12/31/69? That can't be right, can it?

The timestamp isn't really "right", but it shouldn't really hurt either-
that's just when it was "created".  The encyprtion is crappy though and
might be disabled by default (MIT Kerberos recently started disabling
DES and lower encryption because it's horribly insecure).  Check your
/etc/krb5.conf for permitted_enctypes.  Also, after you get a
POSTGRES/host.domain.com ticket using kinit (or psql), do a klist -e and
see if the encryption type of the ticket you got matches that of the
keytab.  If it doesn't, then you might have created multiple keys for
the same princ on the server (not generally a bad thing), but not
exported and loaded all of them into the keytab on the unix system
(which would be a problem...).

        Thanks,

                Stephen
Вложения

Re: GSS Authentication

От
greigwise@comcast.net
Дата:
I just notice that in your message you had more text further down (regarding the DES encryption).  I didn't see that at first.  So, I did klist -e as you suggested and I got this:

Ticket cache: FILE:/tmp/krb5cc_502
Default principal: user@DOMAIN.COM

Valid starting     Expires            Service principal
06/15/10 18:07:33  06/16/10 04:07:36  krbtgt/DOMAIN.COM@DOMAIN.COM
        renew until 06/16/10 04:07:33, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5


Kerberos 4 ticket cache: /tmp/tkt502
klist: You have no tickets cached

Is that the problem?  I don't see anything about permitted enctypes in my krb5.conf.  Should I add something in there to allow DES, or should I recreate my keytab to use a different encryption type?  If so, what should I use?

Thanks again.  I feel like I'm making progress.
Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: pgsql-general@postgresql.org, "Bryan Montgomery" <monty@english.net>
Sent: Tuesday, June 15, 2010 4:25:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> kinit -S POSTGRES/host.domain.com user
>
> (where user is my account name in AD). That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket. Doing it this way though, the keytab file doesn't seem to come into play. Does this point to something in my keytab file being wrong?

Good that you were able to get a ticket manually.  Next you need to try
getting a client application (eg: psql) to get that same ticket.  Before
you run psql, do:

kdestroy
kinit
export PGKRBSRVNAME=POSTGRES
psql -d postgres -h host.domain.com
klist

And see if you acquired the same ticket you got with the manual klist.

> I did this:
>
> klist -ket postgres.keytab
>
> and got:
>
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)
>
> That timestamp seems kinda funky, doesn't it? 12/31/69? That can't be right, can it?

The timestamp isn't really "right", but it shouldn't really hurt either-
that's just when it was "created".  The encyprtion is crappy though and
might be disabled by default (MIT Kerberos recently started disabling
DES and lower encryption because it's horribly insecure).  Check your
/etc/krb5.conf for permitted_enctypes.  Also, after you get a
POSTGRES/host.domain.com ticket using kinit (or psql), do a klist -e and
see if the encryption type of the ticket you got matches that of the
keytab.  If it doesn't, then you might have created multiple keys for
the same princ on the server (not generally a bad thing), but not
exported and loaded all of them into the keytab on the unix system
(which would be a problem...).

        Thanks,

                Stephen
Вложения

Re: GSS Authentication

От
Greig Wise
Дата:
Nope.  I get this:

kinit(v5): Client not found in Kerberos database while getting initial credentials


On Jun 15, 2010, at 10:03 PM, Bryan Montgomery wrote:

I'm not in front of a linux machine, but does
kinit -kt postgres.keytab -S POSTGRES/host.domain.com grant a ticket without asking for the password?

On Tue, Jun 15, 2010 at 2:38 PM, <greigwise@comcast.net> wrote:

As suggested below, I just tried this:

kinit -S POSTGRES/host.domain.com user

(where user is my account name in AD).  That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket.  Doing it this way though, the keytab file doesn't seem to come into play.  Does this point to something in my keytab file being wrong?

I did this: 

klist -ket postgres.keytab

and got:

KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)

That timestamp seems kinda funky, doesn't it?  12/31/69?  That can't be right, can it?


Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: greigwise@comcast.net, pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 8:35:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

        Thanks,

                Stephen


Re: GSS Authentication

От
Stephen Frost
Дата:
Greig,

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> I finally got it working. Problem was that on the windows side on the service account within the account options, we
neededto check "Use DES encryption types for this account". I had that changed on the AD side and that fixed the whole
problem. 

Great, glad to hear you got it working.  Just to reiterate- you really
should be looking at using a 2008 AD with AES encryption types instead
of DES.  DES is depreciated and no longer secure given today's
computers.

    Thanks,

        Stephen
Вложения

Re: GSS Authentication

От
greigwise@comcast.net
Дата:
Bryan, one thing I did have to do on the Linux side was to set dns_lookup_kdc = true in my krb5.conf file in the libdefaults section.  Hope that helps.

Greig

----- Original Message -----
From: greigwise@comcast.net
To: "Bryan Montgomery" <monty@english.net>, sfrost@snowman.net
Cc: "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 10:17:10 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

p { margin: 0; }
OMG!!!

I finally got it working.  Problem was that on the windows side on the service account within the account options, we needed to check "Use DES encryption types for this account".  I had that changed on the AD side and that fixed the whole problem.

Bryan, if you're still trying to get this to work I'd be happy to help if I can.

Thanks all for the help.

Greig

----- Original Message -----
From: "Greig Wise" <greigwise@comcast.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 1:09:16 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

Nope.  I get this:

kinit(v5): Client not found in Kerberos database while getting initial credentials


On Jun 15, 2010, at 10:03 PM, Bryan Montgomery wrote:

I'm not in front of a linux machine, but does
kinit -kt postgres.keytab -S POSTGRES/host.domain.com grant a ticket without asking for the password?

On Tue, Jun 15, 2010 at 2:38 PM, <greigwise@comcast.net> wrote:

As suggested below, I just tried this:

kinit -S POSTGRES/host.domain.com user

(where user is my account name in AD).  That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket.  Doing it this way though, the keytab file doesn't seem to come into play.  Does this point to something in my keytab file being wrong?

I did this: 

klist -ket postgres.keytab

and got:

KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)

That timestamp seems kinda funky, doesn't it?  12/31/69?  That can't be right, can it?


Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: greigwise@comcast.net, pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 8:35:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

        Thanks,

                Stephen


Re: GSS Authentication

От
greigwise@comcast.net
Дата:
2008

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: "Bryan Montgomery" <monty@english.net>, "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 11:32:05 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> So for the -crypto option, what would be your recommendation for what I should use and would this require changes on the DB server side?

What OS are you running on your AD..?  2003?  2008?

        Stephen
Вложения

Re: GSS Authentication

От
greigwise@comcast.net
Дата:
One interesting thing I just came across.  I had another user try to connect to my DB using the GSS authentication and it failed.  I checked everything out on the client side and it seemed to be OK, so I was puzzled.  So then I had another user try and it worked just fine for him.  That's weird, right?  So then I went up and talked to our sysadmin guy who sets up the windows domain stuff and asked him if we could look at the accounts.   The 2 accounts that worked (mine and the 3rd guy) were in a certain group and the other was not a member of that group.  So, I had them put the user into that group.  Then it suddenly starts working fine for that user.  So, evidently, there is some setting on the Windows side for each account which authenticates via GSS that is required for the authentication to work right.  We're going to go through the privs for that group and see if anything sticks out for us, but in the meantime, does anyone have any idea why the one user wouldn't work?

Thanks,
Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: "Bryan Montgomery" <monty@english.net>, "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 11:05:16 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

Greig,

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> I finally got it working. Problem was that on the windows side on the service account within the account options, we needed to check "Use DES encryption types for this account". I had that changed on the AD side and that fixed the whole problem.

Great, glad to hear you got it working.  Just to reiterate- you really
should be looking at using a 2008 AD with AES encryption types instead
of DES.  DES is depreciated and no longer secure given today's
computers.

        Thanks,

                Stephen
Вложения

Re: GSS Authentication

От
greigwise@comcast.net
Дата:
OK.  So, to get it to use a different encryption type, I'm thinking I'd have to specify that when I create the keytab (and then uncheck the Use DES option on the account setup in Windows).  So, when I created my keytab, I used a command like this on the AD side:

ktpass -princ POSTGRES/host.domain.com@DOMAIN.COM -crypto DES-CBC-MD5 -mapuser host -pass mypasswd -out postgres.keytab

So for the -crypto option, what would be your recommendation for what I should use and would this require changes on the DB server side?

Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: greigwise@comcast.net
Cc: "Bryan Montgomery" <monty@english.net>, "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 11:05:16 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

Greig,

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> I finally got it working. Problem was that on the windows side on the service account within the account options, we needed to check "Use DES encryption types for this account". I had that changed on the AD side and that fixed the whole problem.

Great, glad to hear you got it working.  Just to reiterate- you really
should be looking at using a 2008 AD with AES encryption types instead
of DES.  DES is depreciated and no longer secure given today's
computers.

        Thanks,

                Stephen
Вложения

Re: GSS Authentication

От
Stephen Frost
Дата:
* greigwise@comcast.net (greigwise@comcast.net) wrote:
> So for the -crypto option, what would be your recommendation for what I should use and would this require changes on
theDB server side?  

What OS are you running on your AD..?  2003?  2008?

    Stephen
Вложения

Re: GSS Authentication

От
greigwise@comcast.net
Дата:
OMG!!!

I finally got it working.  Problem was that on the windows side on the service account within the account options, we needed to check "Use DES encryption types for this account".  I had that changed on the AD side and that fixed the whole problem.

Bryan, if you're still trying to get this to work I'd be happy to help if I can.

Thanks all for the help.

Greig

----- Original Message -----
From: "Greig Wise" <greigwise@comcast.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 1:09:16 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

Nope.  I get this:

kinit(v5): Client not found in Kerberos database while getting initial credentials


On Jun 15, 2010, at 10:03 PM, Bryan Montgomery wrote:

I'm not in front of a linux machine, but does
kinit -kt postgres.keytab -S POSTGRES/host.domain.com grant a ticket without asking for the password?

On Tue, Jun 15, 2010 at 2:38 PM, <greigwise@comcast.net> wrote:

As suggested below, I just tried this:

kinit -S POSTGRES/host.domain.com user

(where user is my account name in AD).  That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket.  Doing it this way though, the keytab file doesn't seem to come into play.  Does this point to something in my keytab file being wrong?

I did this: 

klist -ket postgres.keytab

and got:

KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)

That timestamp seems kinda funky, doesn't it?  12/31/69?  That can't be right, can it?


Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: greigwise@comcast.net, pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 8:35:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

        Thanks,

                Stephen


Re: GSS Authentication

От
Stephen Frost
Дата:
* greigwise@comcast.net (greigwise@comcast.net) wrote:
> 2008

I'd expect AES256-SHA1 to work then.

    Thanks,

        Stephen
Вложения

Re: GSS Authentication

От
Bryan Montgomery
Дата:
Yeah, the interesting thing is we're supposed to move to AES, but on the current AD it isn't available :) Will be a bit ironic if it is all down to using DES!

On Wed, Jun 16, 2010 at 11:05 AM, Stephen Frost <sfrost@snowman.net> wrote:
Greig,

* greigwise@comcast.net (greigwise@comcast.net) wrote:
> I finally got it working. Problem was that on the windows side on the service account within the account options, we needed to check "Use DES encryption types for this account". I had that changed on the AD side and that fixed the whole problem.

Great, glad to hear you got it working.  Just to reiterate- you really
should be looking at using a 2008 AD with AES encryption types instead
of DES.  DES is depreciated and no longer secure given today's
computers.

       Thanks,

               Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkwY6CwACgkQrzgMPqB3kig89wCfWlskljcakITdMRFGlW55BM0B
qrMAn0M0sHJh5UrEVSqTO3saRGuYLPQC
=KWMB
-----END PGP SIGNATURE-----


Re: GSS Authentication

От
Bryan Montgomery
Дата:
I'm not in front of a linux machine, but does
kinit -kt postgres.keytab -S POSTGRES/host.domain.com grant a ticket without asking for the password?

On Tue, Jun 15, 2010 at 2:38 PM, <greigwise@comcast.net> wrote:

As suggested below, I just tried this:

kinit -S POSTGRES/host.domain.com user

(where user is my account name in AD).  That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket.  Doing it this way though, the keytab file doesn't seem to come into play.  Does this point to something in my keytab file being wrong?

I did this: 

klist -ket postgres.keytab

and got:

KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)

That timestamp seems kinda funky, doesn't it?  12/31/69?  That can't be right, can it?


Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: greigwise@comcast.net, pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 8:35:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

        Thanks,

                Stephen

Re: GSS Authentication

От
Bryan Montgomery
Дата:
Hope you don't mind me resurrecting this thread - but I have made a fair bit of headway in my endeavours.

So, the big issue I had was a bug in Microsoft's ktpass (http://support.microsoft.com/kb/919557) that was on the server.

After that I spent a bit of time on my windows client fiddling trying to get it to work. I had set PGSRVKRBNAME, tried setting PGGSSAPI however, I wasn't using the FQDN of my database server. When I went from dbhost to dbhost.lab2k.net, I was able to connect.

Hopefully this may help someone else in the future.

Now my next step is to see if I can make a connection from a Java application with JDBC.

Bryan.

On Wed, Jun 16, 2010 at 10:17 AM, <greigwise@comcast.net> wrote:
OMG!!!

I finally got it working.  Problem was that on the windows side on the service account within the account options, we needed to check "Use DES encryption types for this account".  I had that changed on the AD side and that fixed the whole problem.

Bryan, if you're still trying to get this to work I'd be happy to help if I can.

Thanks all for the help.

Greig


----- Original Message -----
From: "Greig Wise" <greigwise@comcast.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: "pgsql-general" <pgsql-general@postgresql.org>
Sent: Wednesday, June 16, 2010 1:09:16 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

Nope.  I get this:

kinit(v5): Client not found in Kerberos database while getting initial credentials


On Jun 15, 2010, at 10:03 PM, Bryan Montgomery wrote:

I'm not in front of a linux machine, but does
kinit -kt postgres.keytab -S POSTGRES/host.domain.com grant a ticket without asking for the password?

On Tue, Jun 15, 2010 at 2:38 PM, <greigwise@comcast.net> wrote:

As suggested below, I just tried this:

kinit -S POSTGRES/host.domain.com user

(where user is my account name in AD).  That then asked for my password and when I entered it, it seemed to work. And now klist shows that I have a ticket.  Doing it this way though, the keytab file doesn't seem to come into play.  Does this point to something in my keytab file being wrong?

I did this: 

klist -ket postgres.keytab

and got:

KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/31/69 19:00:00 POSTGRES/host.domain.com@DOMAIN.COM (DES cbc mode with RSA-MD5)

That timestamp seems kinda funky, doesn't it?  12/31/69?  That can't be right, can it?


Thanks again.

Greig

----- Original Message -----
From: "Stephen Frost" <sfrost@snowman.net>
To: "Bryan Montgomery" <monty@english.net>
Cc: greigwise@comcast.net, pgsql-general@postgresql.org
Sent: Saturday, June 12, 2010 8:35:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [GENERAL] GSS Authentication

* Bryan Montgomery (monty@english.net) wrote:
> I've been trying this as well off and on. In my case I'm not convinced the
> AD configuration is correct (And someone else manages that).

Yeah, that can be a challenge..  but it's *definitely* possible to get
it set up and working correctly.

> Can you use kinit with the key tab options to get a good response from the
> server? I think I should be able to do this ..
> $ kinit -V -k -t poe3b.keytab HTTP/poe3b.lab2k.net
> kinit(v5): Preauthentication failed while getting initial credentials

err, I'm not sure that should be expected to work.

What does klist -ek <keytab file> return?  Also, you should be able to
kinit to *your* princ in the AD, and if you can do that, you should be
able to use your princ to request the service princ ticket from the KDC
by doing kinit -S HTTP/poe3b.lab2k.net your.princ

Also, provided your *client* is set up/configured correctly, you should
be able to see that it acquires the ticket (by using klist) when you try
to connect to the server, even if the server is misconfigured.

> I'd be interested to know if you get something different - and the steps you
> went through on the AD side.

You have to create an account in Active Directory for the PG service and
then use:

ktpass /princ POSTGRES/myserver.mydomain.com@MYDOMAIN.COM /mapuser
postgres@mydomain.com /pass mypass /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL /out krb5.keytab

Then copy that krb5.keytab to the server.  Note that you then have to
adjust the server config to have service name set to POSTGRES, and
adjust clients using the environment variables to indiciate they should
ask for POSTGRES (instead of the postgres default).

        Thanks,

                Stephen



Re: GSS Authentication

От
Stephen Frost
Дата:
Bryan,

* Bryan Montgomery (monty@english.net) wrote:
> After that I spent a bit of time on my windows client fiddling trying to get
> it to work. I had set PGSRVKRBNAME, tried setting PGGSSAPI however, I wasn't
> using the FQDN of my database server. When I went from dbhost to
> dbhost.lab2k.net, I was able to connect.

Do you have reverse DNS working..?  That's typically what Kerberos uses
to determine the ticket to request from the KDC.

> Hopefully this may help someone else in the future.

Thanks for the follow-up!

> Now my next step is to see if I can make a connection from a Java
> application with JDBC.

I'd certainly like to hear how this goes..  I don't know if the changes
to support GSSAPI were ever merged into the main JDBC driver.  If not,
perhaps we can encourage them to merge them.  There was a version built
that I was able to use under Linux to successfully auth using Kerberos
(iirc anyway :).

    Thanks!

        Stephen
Вложения