Доброго времени суток. 

Пытаюсь настроить авторизацию postgresql через freeipa (фактически, там идёт привязка к kerberos).

сервер IPA - server.my.domain.local
база с PostgreSQL - database.my.domain.local

настраиваю вот так:
1.    В файле pg_hba.conf прописываем разрешение на доступ из определённой сети:
host    all        all        192.168.0.0/24        gss 

2.    В файле postgresql.conf прописываем обращение к keytab файлу:
# Kerberos and GSSAPI
krb_server_keyfile = '/var/lib/pgsql/9.2/data/pg.keytab'
krb_srvname = 'postgres'        # (Kerberos only)

3.    Добавляем сервис PostgreSQL:
ipa service-add postgres/server.my.domain.local

4.    Генерируем ключ:
ipa-getkeytab -s server.my.domain.local -p postgres/[email protected]  -k /var/lib/pgsql/data/9.2/pg.keytab

5.    Меняем права:
chown postgres:postgres /var/lib/pgsql/9.2/data/pg.keytab

6.     Перезапускаем PostgreSQL

7.    делаю вызов с компа, где стоит PostgreSQL:
psql -h database.my.domain.local


Ошибка: DEBUG:  InitPostgres
DEBUG:  my backend ID is 1
DEBUG:  StartTransaction
DEBUG:  checkpointer updated shared memory configuration values
DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
DEBUG:  CommitTransaction
DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
DEBUG:  forked new backend, pid=17203 socket=11
DEBUG:  postmaster child[17203]: starting with (
DEBUG:    postgres
DEBUG:    [email protected]
DEBUG:  )
DEBUG:  InitPostgres
DEBUG:  my backend ID is 2
DEBUG:  StartTransaction
DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
DEBUG:  Processing received GSS token of length 654
DEBUG:  gss_accept_sec_context major: 0, minor: 0, outlen: 156, outflags: 1b2
DEBUG:  sending GSS response token of length 156
DEBUG:  sending GSS token of length 156
LOG:  provided user name ([email protected]) and authenticated user name (rembo) do not match
FATAL:  GSSAPI authentication failed for user "[email protected]"
DEBUG:  shmem_exit(1): 7 callbacks to make
DEBUG:  proc_exit(1): 3 callbacks to make
DEBUG:  exit(1)
DEBUG:  shmem_exit(-1): 0 callbacks to make
DEBUG:  proc_exit(-1): 0 callbacks to make
DEBUG:  reaping dead processes
DEBUG:  server process (PID 17203) exited with exit code 1


при вызове - psql -h database.my.domain.local
ошибка - psql: FATAL:  role "rembo" does not exist

если указать пользователя с указанием домена (как в керберосе) - psql -h database.my.domain.local -U [email protected]
ошибка - psql: FATAL:  GSSAPI authentication failed for user "rembo/[email protected]

Вход в систему выполняется через IPA. В чём может быть проблема ?

Это сообщение отредактировал(а) minigo - 30.9.2013, 15:00

К сожалению, не работал с PostgreSQL (возможно, в проблеме её специфика), но об аутентификацию на IPA сервере бился долго - неделю где-то... Но мне нужны были SSL-сертификаты, а не keytabы. Да и с PKI была куча проблем.

Первое, что приходит на ум - проблемы не на БД, а на самой IPA. Мы как-то после убитого дня (в течение которого IPA была перезагружена) обнаружили через chckconfig, что сервис sssd по умолчанию вообще не стартует! Перезапустили его, прописали в конфиги его автозапуск, и всё пошло. 

В общем, что на IPA пишется в логи Апача, когда вы стучитесь на неё с БД? Здесь могут быть основные разгадки... Так же может быть интересен auditlog.

P. S. До Python API (работающего поверх XML-RPC клиента с встроенной Kerberos-аутентификацией) строили своё решение на взаимодействии с IPA по ssh. Тоже хотели заходить на IPA своей прогой через Kerberos, но столкнулись с отсутствием хоть сколько-нибудь нормально документированного интерфейса GSS-API для протокола SSH  на языке С. В итоге пришлось всё делать через ключи.