Thread: GSS Authentication
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
* 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
Attachment
kinit(v5): Preauthentication failed while getting initial credentials
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
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
Attachment
* 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
Attachment
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
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
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
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 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
----- 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
---- --------------------------------------------------------------------------
3 POSTGRES/hostname.domain.com@DOMAIN.COM
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
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
Attachment
* 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
Attachment
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
Attachment
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
Attachment
I'm not in front of a linux machine, but doeskinit -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
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
Attachment
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
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:
I'm not in front of a linux machine, but doeskinit -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
----- 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
Attachment
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
Attachment
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
Attachment
* 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
Attachment
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:
I'm not in front of a linux machine, but doeskinit -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
* greigwise@comcast.net (greigwise@comcast.net) wrote: > 2008 I'd expect AES256-SHA1 to work then. Thanks, Stephen
Attachment
Greig,> 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-----
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
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.
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 credentialsOn Jun 15, 2010, at 10:03 PM, Bryan Montgomery wrote:I'm not in front of a linux machine, but doeskinit -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
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