Re: [GENERAL] GSS Authentication
Bryan, * Bryan Montgomery (mo...@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 signature.asc Description: Digital signature
Re: [GENERAL] GSS Authentication
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, 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" > To: "Bryan Montgomery" > Cc: "pgsql-general" > 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, 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@domain.com<http://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" >> To: "Bryan Montgomery" >> Cc: greigw...@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 (mo...@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 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@mydomain.com<http://mydomain.com/>/mapuser >> postg...@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: [GENERAL] GSS Authentication
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, 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@domain.com<http://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" > To: "Bryan Montgomery" > Cc: greigw...@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 (mo...@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 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@mydomain.com<http://mydomain.com/>/mapuser > postg...@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: [GENERAL] GSS Authentication
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 wrote: > Greig, > > * greigw...@comcast.net (greigw...@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: [GENERAL] GSS Authentication
* greigw...@comcast.net (greigw...@comcast.net) wrote: > 2008 I'd expect AES256-SHA1 to work then. Thanks, Stephen signature.asc Description: Digital signature
Re: [GENERAL] GSS Authentication
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" To: "Bryan Montgomery" Cc: "pgsql-general" 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, < greigw...@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" < sfr...@snowman.net > To: "Bryan Montgomery" < mo...@english.net > Cc: greigw...@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 ( mo...@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 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 postg...@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: [GENERAL] GSS Authentication
* greigw...@comcast.net (greigw...@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 signature.asc Description: Digital signature
Re: [GENERAL] GSS Authentication
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@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" To: greigw...@comcast.net Cc: "Bryan Montgomery" , "pgsql-general" Sent: Wednesday, June 16, 2010 11:05:16 AM GMT -05:00 US/Canada Eastern Subject: Re: [GENERAL] GSS Authentication Greig, * greigw...@comcast.net (greigw...@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 signature.asc Description: Digital signature -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GSS Authentication
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" To: greigw...@comcast.net Cc: "Bryan Montgomery" , "pgsql-general" Sent: Wednesday, June 16, 2010 11:05:16 AM GMT -05:00 US/Canada Eastern Subject: Re: [GENERAL] GSS Authentication Greig, * greigw...@comcast.net (greigw...@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 signature.asc Description: Digital signature -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GSS Authentication
2008 - Original Message - From: "Stephen Frost" To: greigw...@comcast.net Cc: "Bryan Montgomery" , "pgsql-general" Sent: Wednesday, June 16, 2010 11:32:05 AM GMT -05:00 US/Canada Eastern Subject: Re: [GENERAL] GSS Authentication * greigw...@comcast.net (greigw...@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 signature.asc Description: Digital signature -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GSS Authentication
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: greigw...@comcast.net To: "Bryan Montgomery" , sfr...@snowman.net Cc: "pgsql-general" Sent: Wednesday, June 16, 2010 10:17:10 AM GMT -05:00 US/Canada Eastern Subject: Re: [GENERAL] GSS Authentication 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" To: "Bryan Montgomery" Cc: "pgsql-general" 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, < greigw...@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" < sfr...@snowman.net > To: "Bryan Montgomery" < mo...@english.net > Cc: greigw...@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 ( mo...@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 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 postg...@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: [GENERAL] GSS Authentication
Greig, * greigw...@comcast.net (greigw...@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 signature.asc Description: Digital signature
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, 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@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" > To: "Bryan Montgomery" > Cc: greigw...@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 (mo...@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 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@mydomain.com /mapuser > postg...@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: [GENERAL] GSS Authentication
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: u...@domain.com Valid starting Expires Service principal 06/15/10 18:07:33 06/16/10 04:07:36 krbtgt/domain@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" To: greigw...@comcast.net Cc: pgsql-general@postgresql.org, "Bryan Montgomery" Sent: Tuesday, June 15, 2010 4:25:55 PM GMT -05:00 US/Canada Eastern Subject: Re: [GENERAL] GSS Authentication * greigw...@comcast.net (greigw...@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@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 signature.asc Description: Digital signature -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GSS Authentication
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 [u...@client ~]$ kdestroy [u...@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 [u...@client ~]$ kinit Password for u...@domain.com: [u...@client ~]$ klist Ticket cache: FILE:/tmp/krb5cc_503 Default principal: u...@domain.com Valid starting Expires Service principal 06/15/10 17:16:37 06/16/10 03:16:42 krbtgt/domain@domain.com renew until 06/16/10 03:16:37 Kerberos 4 ticket cache: /tmp/tkt503 klist: You have no tickets cached [u...@client ~]$ psql -d postgres -h server.DOMAIN.COM psql: FATAL: accepting GSS security context failed DETAIL: Miscellaneous failure: Unknown code krb5 181 [u...@client ~]$ klist Ticket cache: FILE:/tmp/krb5cc_503 Default principal: u...@domain.com Valid starting Expires Service principal 06/15/10 17:16:37 06/16/10 03:16:42 krbtgt/domain@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@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" To: greigw...@comcast.net Cc: pgsql-general@postgresql.org, "Bryan Montgomery" Sent: Tuesday, June 15, 2010 4:25:55 PM GMT -05:00 US/Canada Eastern Subject: Re: [GENERAL] GSS Authentication * greigw...@comcast.net (greigw...@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@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 signature.asc Description: Digital signature -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GSS Authentication
* greigw...@comcast.net (greigw...@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@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 signature.asc Description: Digital signature
Re: [GENERAL] GSS Authentication
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@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" To: "Bryan Montgomery" Cc: greigw...@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 (mo...@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 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@mydomain.com /mapuser postg...@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 signature.asc Description: Digital signature -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GSS Authentication
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: greigw...@comcast.net To: "Stephen Frost" 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 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@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: F: 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: 0: 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: 0: checkpoint record is at 1/BD20 2010-06-14 15:12:21 EDTLOCATION: StartupXLOG, xlog.c:5340 2010-06-14 15:12:21 EDTDEBUG: 0: redo record is at 1/BD20; shutdown TRUE 2010-06-14 15:12:21 EDTLOCATION: StartupXLOG, xlog.c:5366 2010-06-14 15:12:21 EDTDEBUG: 0: 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: 0: next MultiXactId: 1; next MultiXactOffset: 0 2010-06-14 15:12:21 EDTLOCATION: StartupXLOG, xlog.c:5373 2010-06-14 15:12:21 EDTDEBUG: 0: 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: 0: 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: 0: 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: 0: exit(0) 2010-06-14 15:12:21 EDTLOCATION: proc_exit, ipc.c:135 2010-06-14 15:12:21 EDTDEBUG: 0: 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: 0: 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: 0: reaping dead processes 2010-06-14 15:12:21 EDTLOCATION: reaper, postmaster.c:2238 2010-06-14 15:12:21 EDTLOG: 0: autovacuum launcher started 2010-06-14 15:12:21 EDTLOCATION: AutoVacLauncherMain, autovacuum.c:529 2010-06-14 15:12:21 EDTLOG: 0: 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: 0: 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: 0: 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: 0: 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: 0: shmem_exit(1): 0 callbacks to make 2010-06-14 15:12:26 EDT
Re: [GENERAL] GSS Authentication
rver 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: 0: postmaster received signal 15 2010-06-14 15:12:31 EDTLOCATION: pmdie, postmaster.c:2090 2010-06-14 15:12:31 EDTLOG: 0: received smart shutdown request 2010-06-14 15:12:31 EDTLOCATION: pmdie, postmaster.c:2105 2010-06-14 15:12:31 EDTLOG: 0: autovacuum launcher shutting down 2010-06-14 15:12:31 EDTLOCATION: AutoVacLauncherMain, autovacuum.c:760 2010-06-14 15:12:31 EDTDEBUG: 0: 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: 0: 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: 0: exit(0) 2010-06-14 15:12:31 EDTLOCATION: proc_exit, ipc.c:135 2010-06-14 15:12:31 EDTDEBUG: 0: 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: 0: 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: 0: reaping dead processes 2010-06-14 15:12:31 EDTLOCATION: reaper, postmaster.c:2238 2010-06-14 15:12:31 EDTDEBUG: 0: 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: 0: 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: 0: exit(0) 2010-06-14 15:12:31 EDTLOCATION: proc_exit, ipc.c:135 2010-06-14 15:12:31 EDTDEBUG: 0: 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: 0: 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: 0: reaping dead processes 2010-06-14 15:12:31 EDTLOCATION: reaper, postmaster.c:2238 2010-06-14 15:12:31 EDTLOG: 0: shutting down 2010-06-14 15:12:31 EDTLOCATION: ShutdownXLOG, xlog.c:6234 2010-06-14 15:12:31 EDTDEBUG: 0: executing archive command "cp pg_xlog/0001000100BD /postgresdb/log_arch/0001000100BD To: greigw...@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 * greigw...@comcast.net (greigw...@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: [GENERAL] GSS Authentication
Hi Steven, Thanks for the info here. In particular, On Sat, Jun 12, 2010 at 12:58 AM, Stephen Frost 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: [GENERAL] GSS Authentication
* Bryan Montgomery (mo...@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 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@mydomain.com /mapuser postg...@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 signature.asc Description: Digital signature
Re: [GENERAL] GSS Authentication
Bryan, * Bryan Montgomery (mo...@english.net) wrote: > On Sat, Jun 12, 2010 at 12:58 AM, Stephen Frost 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@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 signature.asc Description: Digital signature
Re: [GENERAL] GSS Authentication
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, 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: 0: 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: 0: 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: [GENERAL] GSS Authentication
* greigw...@comcast.net (greigw...@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 signature.asc Description: Digital signature
[GENERAL] GSS Authentication
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: 0: 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: 0: 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
