Re: configuration kerberos in Postgre sql - Mailing list pgsql-admin

Hi Rahimeh,

Is PG on the same box as the kadmind?

rahimeh khodadadi wrote:
> have never been worked  with krb5 in postgresql?
>
> On 10/12/09, rahimeh khodadadi <rahimeh.khodadadi@gmail.com> wrote:
>> nobody could help me?
>>
>> On Sun, Oct 11, 2009 at 5:06 PM, rahimeh khodadadi <
>> rahimeh.khodadadi@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> after compling the postgresql --with-krb5  and setting up the krb5-server
>>> in centos, I configured the *postgresql.conf* as bellow:
>>>
>>> *krb_server_keyfile = '/var/kerberos/krb5kdc/kadm5.keytab'*
>>> *krb_srvname = 'POSTGRES' *       # (Kerberos only)
>>> #krb_caseins_users = off

I like to specify my krb_server_hostname explicitly here.

>>> and
>>>
>>> my *pg_hba.conf* is :
>>>
>>> # "local" is for Unix domain socket connections only
>>> local   all         postgres                         trust
>>> # IPv4 local connections:
>>> host   all         *frank*       0.0.0.0/0            krb5
>>> #host    all         all         127.0.0.1/32      trust
>>> # IPv6 local connections:
>>> host    all         all         ::1/128               trust
>>>
>>>
>>> ,and kdc.conf
>>>
>>> kdcdefaults]
>>>  v4_mode = nopreauth
>>>  kdc_tcp_ports = 88
>>>
>>> [realms]
>>>  EXAMPLE.COM = {
>>>   #master_key_type = des3-hmac-sha1
>>>  * acl_file = /var/kerberos/krb5kdc/kadm5.acl*
>>>   dict_file = /usr/share/dict/words
>>>   admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

If this is the same machine as PG, I'm not sure why you have the same file here as
for the keytab to keep the PG service principal in.  My manpage for kdc.conf says
that admin_keytab specifies the keytab to be used by kadmin to authenticate to the
database, so really shouldn't be kept very distinct from the keytab with the PG
service principal.

>>>   supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal
>>> des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4
>>> des-cbc-crc:afs3
>>>  }
>>>
>>> Then, I created the user frank  as :
>>>
>>>  kadmin.local
>>> Authenticating as principal rahimeh/admin@EXAMPLE.COM with password.
>>> kadmin.local: * ank frank*
>>> WARNING: no policy specified for frank@EXAMPLE.COM; defaulting to no
>>> policy
>>> Enter password for principal "frank@EXAMPLE.COM":
>>> Re-enter password for principal "frank@EXAMPLE.COM":
>>>
>>> *kadmin.local: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab frank*
>>> Entry for principal frank with kvno 2, encryption type Triple DES cbc
>>> mode
>>> with HMAC/sha1 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
>>> Entry for principal frank with kvno 2, encryption type ArcFour with
>>> HMAC/md5 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
>>> Entry for principal frank with kvno 2, encryption type DES with HMAC/sha1
>>> added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
>>> Entry for principal frank with kvno 2, encryption type DES cbc mode with
>>> RSA-MD5 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.

But for PG you'll need a keytab with the service principal you've defined to be
POSTGRES/<hostname>@EXAMPLE.COM in it.

>>> Finally, it gives error like:
>>>
>>> [root@localhost ~]# *kinit frank* -t /var/kerberos/krb5kdc/kadm5.keytab
>>> Password for frank@EXAMPLE.COM:
>>> *kinit(v5): Password incorrect while getting initial credentials*

I've never had much joy myself when getting tickets from a -t keytab, I usually just
kinit and enter a password instead.

>>> or
>>>
>>> in cmd when I run this instruction the below error is shown.
>>>
>>> [root@localhost bin]# ./psql -h 127.0.0.1  -U frank
>>> *psql: krb5_sendauth: Bad application version was sent (via sendauth)*

To construct the service principal the library takes the the -h argument, then gets
the A record for it (if applicable), then gets the PTR record for the A record to get
the hostname for the service principal name (unless you're using Windows I have
found, in which case it just stops and takes the originally given hostname if an A
record exists).  Just use a non-127 address instead, it'll make things a lot easier
to keep straight.  For that matter, /etc/hostname and /etc/resolv.conf would be good
to see too because of their importance here.

HTH,
Geoff


---------
Geoff Tolley
DBA/Systems Administrator

YouGovPolimetrix
285 Hamilton Avenue Suite 200
Palo Alto, CA 94301
geoff.tolley@yougov.com
http://www.yougov.com/