kerberos + postgresql аутентификация

 
0
 
Linux/Unix
ava
minigo | 30.09.2013, 15:26
Доброго времени суток.

Пытаюсь настроить авторизацию postgresql через freeipa (фактически, там идёт привязка к kerberos).
настраиваю вот так:
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.    Проверка:
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
Comments (1)
ava
vitalyisaev2 | 30.09.2013, 17:05 #
К сожалению, не работал с 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  на языке С. В итоге пришлось всё делать через ключи. 
Please register or login to write.
Firm of day
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Contributors
advanced
Submit