The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Репликация LDAP с поддержкой kerberos (ldap replication auth kerberos)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: ldap, replication, auth, kerberos,  (найти похожие документы)
From: ZIO Date: Mon, 23 Oct 2010 17:02:14 +0000 (UTC) Subject: Репликация LDAP с поддержкой kerberos Оригинал: http://my.opera.com/Zl0/blog/2010/09/20/syncrepl-ldap-kerberos-support Что такое репликация и зачем она нужна, в этой статье вы не найдете, здесь я расскажу только о том как настроить репликацию используя для авторизации слэйвов только kerberos, а так же некоторые вещи которые чаще всего пропускаются в статьях про репликацию, и лично у меня вызывали вопросы. Существовала инфраструктура, настроенный ldap с авторизацией клиентов к нему только по kerberos, никаких логин-паролей, никаких специальных админских учеток в ldap не было. И были еще несколько slave серверов, которые реплицировались по средством slapcat->scp->replace ldapDB. Неудобно жутко, захотелось чтобы все изменения сразу разливались по slave, хоть изменений вносилось и немного, но актуализация данных нужна. Выбор пал на syncrepl, опять же, "почему?" можно почитать в других статьях. Как его настроить вроде тоже не сложно, с master вообще сначала вопросов не возникло, но только сначала. Со slave начались вопросы "A кого указывать authcid, у меня же kerberos? Укажу принципла, как он получит тикет?" Все вопросы не буду расписывать, распишу только решение с комментариями, как сделать чтобы работало, и безопасность не пострадала. Начну наоборот со SLAVE, т.к будет проще понять что и зачем. [slapd.conf] # Назовем его псевдопользователем, потому что как таковой # этой записи в директории нет, и не будет, но тот кто # будет авторизовываться под этим именем будет иметь все # права на базу. Подробнее об этом будет ниже. rootdn "cn=replicator,dc=domain,dc=ru" # Индексы базы, первая запись просто для ускорения поиска # по базе, вторая для создания уникальных uid, используется # в репликации index objectClass,uid,uidNumber,gidNumber,memberUid eq index entryCSN,entryUUID eq # Это маска, для авторизации наших slave. authz-regexp "uid=[^,]*/replicator,cn=gssapi,cn=auth" "cn=replicator,dc=domain,dc=ru" # База только на чтение, этот параметр не влияет на то, сможет # ли репликатор обновлять данные в базе, скажу что сможет. readonly on # Описание самой репликации. syncrepl rid=111 provider=ldap://master.domain.ru:389/ type=refreshAndPersist retry="60 +" searchbase="dc=domain,dc=ru" schemachecking=off starttls=yes bindmethod=sasl saslmech=gssapi realm=domain.ru authcid="ldap-slave1/[email protected]" # Куда переправлять запросы на запись, если кто-то попытается # сделать запись на этот slave updateref ldap://master.domain.ru Теперь подробнее о том как получается replicator. Для каждого slave сервера необходимо создать на KDC по дополнительному принциплу. ktadd -randkey ldap-slave1/[email protected] ktadd -randkey ldap-slave2/[email protected] Именно такие принциплы при обращение к мастеру будут, с помощью authz-regexep матчиться в юзера replicator, который в конфиге у нас rootdn , т.е пользователь со всеми правами на базу. В начале я дал ему даже специально права на запись. #access to * # by ssf=128 dn="cn=replicator,dc=domain,dc=ru" write # by * break но потом это оказалось излишне. Как заставить slave использовать kerberos для авторизации как ldap клиент? Оказалось есть уже специальная тулза, которая умеет использовать keytab, получать тикет и обновлять его, после того как он протухнет. aptitude install kstart Пришлось ей написать правильный init скрипт, он прилагается. k5start-init #! /bin/sh # /etc/init.d/k5start: start the kernel log daemon. ### BEGIN INIT INFO # Provides: k5start # Required-Start: $syslog # Required-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Kinit ### END INIT INFO PATH=/bin:/usr/bin:/sbin:/usr/sbin pidfile=/var/run/k5start.pid binpath=/usr/bin/k5start keytab=/etc/ldap/replicator.keytab oid=$(cat /etc/passwd |grep openldap | cut -d: -f3) test -f $binpath || exit 0 . /lib/lsb/init-functions case "$1" in start) log_begin_msg "Starting k5start daemon..." start-stop-daemon --start --pidfile $pidfile \ --exec $binpath -- -p $pidfile \ -U -f $keytab -b -K 10 -l 8h -k /tmp/krb5cc_${oid} -o openldap log_end_msg $? ;; stop) log_begin_msg "Stopping k5start daemon..." start-stop-daemon --stop --pidfile $pidfile rm -f $pidfile && rm -f /tmp/krb5cc_${oid} log_end_msg $? ;; restart|force-reload) log_begin_msg "Reloading k5start daemon..." /etc/init.d/k5start stop /etc/init.d/k5start start log_end_msg $? ;; *) log_success_msg "Usage: /etc/init.d/k5start {start|stop|restart|force-reload }" exit 1 esac exit 0 Перед запуском утилиты на slave нужно получить тот самый keytab для принципла и поставить ему правильные права. kadmin -p mylogin/admin -q "ktadd -k /etc/ldap/replicator.keytab ldap-slave1/[email protected]" chown openldap:openldap /etc/ldap/replicator.keytab chmod 600 /etc/ldap/replicator.keytab Если сохранили под другим именем и/или в другом месте, не забудьте подправить переменную keytab в init-скрипте. Аналогичные действия делаются на всех slave, для каждого свой keytab, в названии я использовал имя хоста, можно в принципе что угодно, главное чтобы маска соблюдалась (hostname/replicator), можно и вообще использовать один keytab на всех, но уже 1) не секурно 2) в логах будет путаница. После запуска k5start в /tmp/ должны увидеть кэш тикета нашего openldap пользователя. #ls -la /tmp total 16 drwxrwxrwt 3 root root 4096 Sep 20 18:42 . drwxr-xr-x 22 root root 4096 Jul 19 2009 .. -rw------- 1 openldap openldap 960 Sep 20 13:42 krb5cc_104 На slave должно быть все готово, можно переходить к master. MASTER [slapd.conf] # Загружаем модули moduleload syncprov # Строим индексы index entryCSN,entryUUID eq # Матчим наших прициплов со slave серверов, в # полноценного пользователя с особыми правами. authz-regexp "uid=[^,]*/replicator,cn=gssapi,cn=auth" "cn=replicator,dc=domain,dc=ru" # Включаем репликацию. overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 # Replicator должен иметь права на то чтобы читать всю базу, ну или какую то # ветку, если он реплицирует тольчасть дерева. access to * by peername.ip="192.168.1.0%255.255.255.0" sasl_ssf=56 dn="cn=replicator,dc=domain,dc=ru" read by peername.ip="192.168.2.0%255.255.255.0" sasl_ssf=56 dn="cn=replicator,dc=domain.ru,dc=ru" read by peername.ip="192.168.32.0%255.255.252.0" sasl_ssf=56 dn="cn=replicator,dc=domain,dc=ru" read by * break На master никаких kstart запускать не нужно, он ждет только клиентов, и проверяет их валидность через kerberos. Если все готово перезапускаем службы на master, потом на slave внимательно смотрим в лог, ищем похожую строчку master slapd[11612]: conn=4 op=3 BIND authcid="ldap-slave1/replicator" authzid="ldap-slave1/replicator" master slapd[11612]: conn=4 op=3 BIND dn="cn=replicator,dc=domain,dc=ru" mech=GSSAPI sasl_ssf=56 ssf=128 Которая говорит нам что slave удачно авторизовался и правильно заматчился. После этого можно вносить изменения на master, и смотреть как они почти моментально принимаются на slave серверах. Кстати, так же можно запускать slave сервера совсем без базы, если все правильно настроено, вся база сразу же после запуска реплицируется с master на slave. Правильно работающая репликая должна оставлять логи примерно такого содержания [Loglevel debug] slapd[3003]: send_ldap_result: conn=-1 op=0 p=0 slapd[3003]: send_ldap_result: err=0 matched="" text="" slapd[3003]: syncrepl_entry: rid=222 be_search (0) slapd[3003]: syncrepl_entry: rid=222 uid=user_test,o=TEST,dc=domain,dc=ru slapd[3003]: slap_queue_csn: queing 0xb5c025e8 20100920155901.638546Z#000000#000#000000 slapd[3003]: bdb_modify: uid=user_test,o=TEST,dc=domain,dc=ru slapd[3003]: bdb_dn2entry("uid=user_test,o=test,dc=domain,dc=ru") slapd[3003]: bdb_modify_internal: 0x000000e5: uid=user_test,o=TEST,dc=domain,dc=ru slapd[3003]: <= acl_access_allowed: granted to database root slapd[3003]: bdb_modify_internal: replace mail slapd[3003]: bdb_modify_internal: replace entryCSN slapd[3003]: bdb_modify_internal: replace modifiersName slapd[3003]: bdb_modify_internal: replace modifyTimestamp slapd[3003]: => key_change(DELETE,e5) slapd[3003]: bdb_idl_delete_key: e5 [5efbbb83] slapd[3003]: <= key_change 0 slapd[3003]: => key_change(DELETE,e5) slapd[3003]: bdb_idl_delete_key: e5 [7faff89e] slapd[3003]: <= key_change 0 slapd[3003]: => key_change(DELETE,e5) ....................................................... slapd[3003]: => key_change(ADD,e5) slapd[3003]: bdb_idl_insert_key: e5 [acbfa9c7] slapd[3003]: <= key_change 0 slapd[3003]: => key_change(ADD,e5) slapd[3003]: bdb_idl_insert_key: e5 slapd[3003]: <= key_change 0 slapd[3003]: => entry_encode(0x000000e5): uid=user_test,o=TEST,dc=domain,dc=ru slapd[3003]: bdb_modify: updated id=000000e5 dn="uid=user_test,o=TEST,dc=domain,dc=ru" slapd[3003]: send_ldap_result: conn=-1 op=0 p=0 slapd[3003]: send_ldap_result: err=0 matched="" text="" slapd[3003]: slap_graduate_commit_csn: removing 0xb5c13ba8 20100920155901.638546Z#000000#000#000000 slapd[3003]: syncrepl_entry: rid=222 be_modify (0) slapd[3003]: slap_queue_csn: queing 0xb5c025e8 20100920155901.638546Z#000000#000#000000 О чем это говорит, что slave узнал что данные изменились, ключики удалились, новые ключики добавились, транзакция закоммитилась. Что нужно помнить, что может вылезти и как это лечить. 1. Не забывать сделать индексы, а именно sudo -u openldap slapindex 2. Если replicator не мачится по regex, возможно в slapd.conf у вас есть параметры sasl-realm DOMAIN.RU sasl-host kdc.domain.ru в таком случае к принциплу при авторизации будет добавлен еще cn=sasl, т.е regex нужно поправить. authz-regexp "uid=[^,]*/replicator,cn=sasl,cn=gssapi,cn=auth" "cn=replicator,dc=domain,dc=ru" 3. Backends на master и slave должны быть одинаковы hdb<->hdb, bdb<->bdb 4. Ошибки типа "warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: Permission denied" лечится chown root:sasl /etc/sasldb2 chmod 660 /etc/sasldb2 5. Убедитесь что cache тикета на слейвах периодически обновляется, время создания файла должно обновляться. Переодичность обновления выставляется в init скрипте k5start 6. При отладке не забывать включать loglevel debug в slapd.conf # Level debug loglevel 32767

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру